Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children

[TW_Tones]

@nemo

You want a parallel tag-like structure - hence a seperate name makes sense. And you’ve proposed an alternate way to populate that structure.

Just for clarity, not disputation. No I want a flag method. A destinct no-touch mechanisium. Although I plan to make it as feature rich as tags as you support.

The no touch approach would posibly have been best introduced originaly for tags, but that ship has sailed.

• Now this destinction is importiant, and unless the core supports it even more importiant.
• Note how you can share a set of flags without sharing the tiddlers they flag.

Back to OT, tags that can have there use to include/exclude, may need some differentiation as well.

• Although when you use a tag in TiddlyWiki script it may not be as importiant. The designer chooses how to use a tag in their own code, but perhaps not in core processes.

[CodaCoder]

Reminder: This is about tags and tagging and a proposed evolution thereof. Flags are being discussed elsewhere.

[TW_Tones]

Thanks, but in this case it relates to compare and contrast the two.

But yes, let us not let the two to bleed into each other

[Yaisog]

@Springer

So, do you share my impression that this approach would require javascript?

Yes, modifying the behavior of tag[] and tagging[] involves JavaScript. This shouldn’t be too hard, though, give me a day to so to come up with a proof-of-concept.

As @Springer points out, it would intrinsically be backward-compatible because you’d have to enter a list of tiddler(s) into some field of the tag tiddler to make it happen. Without that, there will be no change in behavior. If it’d only work with a suffix, you again would have to modify the core templates in a lot of places.

We’d need a field name that no one has used on tag tiddlers, though. Just to throw my hat in the ring, I like unlist as something short and in contrast to the often-used list.

Assuming the behavior of tag[] is changed to exclude anything in the given field of a tag tiddler, if it exists, what should !tag[] do? Still remove everything with that tag? Except for the listed tiddlers?

[nemo]

@Yaisog

Assuming the behavior of tag[] is changed to exclude anything in the given field of a tag tiddler, if it exists, what should !tag[] do? Still remove everything with that tag? Except for the listed tiddlers?

I think !tag[] should only care about what is and isn’t tagged as the final result. That a commonplace tid wanted to be tagged, and then the tag tid veto’d that tagging, is irrelevant, since the result is “not tagged”.

re: unlist - I like the short and contrast, but aren’t lists used for other things than tags? I’d suggest something with “tag” explicitly in the field name. tag-exclusion or tag-deallocate perhaps (the latter making for the easy tag-allocate partner, should that eventuate).

Some tids achieve tags. Some tids have tags thrust upon them. Some tids have tags denied to them.

[pmario]

@nemo

I think that’s the difference between us here. You want a parallel tag-like structure - hence a seperate name makes sense. And you’ve proposed an alternate way to populate that structure.

I’m not sold on the need for the parallel structure, but the enhanced way of populating I am on board with - I just want it for the existing tags. (well, conceptually at least. As I speculated above, my gut feel is that it’ll be a performance nightmare)

I think, both ideas are interesting and valid on their own. They differ in the level, where the need to be implemented.

[TW_Tones]

@TW_Tones

Again touching on Tag ($:/tags/ViewTemplate) allowed to “disregard” some tag-children

I wonder if this and another field on the tag tiddlers would go a long way with @Springer’s issue such as a list-filter on tags that is applied as a subfilter whenever listing a tag. That filter can contain both includes and excludes as desired and would be far simpler than a multi-field solution.

• The local tiddler could override the tags list-filter by having a variable set, its own field, and if neither exists look for a global list-filter variable. The default being no list-filter/<<list-filter>>

In the related thread I stumbled upon this idea above. All it would require is the addition to any tag listing in the view template a subfilter<list-filter>

• I must add to the list of places to seek the list-filter to apply to look in the tag tiddler as well.

[Yaisog]

I created a Sharing Edition with new tag[] and tagging[] functionality as a proof-of-concept:

Filtered Tagging - Sharing Edition TW

For now it uses the unlist field name, though this is easily changed.

It also applies the ignore list to !tag[], because for consistency it makes sense to treat any tiddler on the unlist list as not having that tag, in any situation. Otherwise it might be confusing and/or restricted to a particular application.

Picking up on the suffix idea, it may make sense to add some suffix like raw to deactivate the filtering / ignore the unlist field, in cases where you really want all tiddlers with that tag. This keeps the advantage of not having to change core templates to integrate the filtering.

[pmario]

IMO That does not scale. If 2 plugins want to “unlist” different tiddlers, they overwrite each other.

So the unlist field internally needs to be handled as an unlist-filter, that defines a rule, how to “add” elements to the unlist-list.

---

I am not sure, if tagging[] would / should need to respect unlist - thinking …

[TW_Tones]

@pmario

So the unlist field internally needs to be handled as an unlist-filter, that defines a rule, how to “add” elements to the unlist-list.

What about the recent suggestion on mine of a list-filter such that we can include and exclude using a list of titles or a filter?

I could see the addition of another parameter on the tag operators called subfilter, list all tagged after applying the subfilter in that parameter,eg;

• [all[shadows+tiddlers]tag[$:/tags/ViewTemplate],<list-filter>!is[draft]]
  or
• [all[shadows+tiddlers]tag[$:/tags/ViewTemplate]subfilter<list-filter>!is[draft]]

[Yaisog]

Keep in mind that in the OP the primary aim was to toggle parts of the ViewTemplate without overwriting shadow tiddlers (i.e. modifying neither core templates’ tags nor logic). The PoC does just that in a minimally-invasive backwards-compatible way.

Adding parameters to tag operators would require core templates to be changed to incorporate this.

Plugins would just override the shadow tiddlers as usual to remove their tags if necessary. This will keep them being shadows and avoids conflicts. I see modifying tag tiddlers in the proposed way as more of a manual intervention technique.

[TW_Tones]

@Yaisog

I created a Sharing Edition with new tag[] and tagging[] functionality as a proof-of-concept:

Filtered Tagging - Sharing Edition TW

I will have a look at your solution but does it not modify core tiddlers?

[Yaisog]

@TW_Tones

I will have a look at your solution but does it not modify core tiddlers?

“minimally-invasive” does not mean “non-invasive”.

Unless you additionally add a tag tiddler and give it an unlist field, no core functionality is changed.

PS: Actually, these filter operators would not have to overwrite core tiddlers. They could come in a plugin or any manually created tiddler with an arbitrary name and would simply override the functionality of these filter operators upon initialization of the wiki, because they are loaded later.

[Yaisog]

Here is an improved version that adds the optional raw suffix to both tag[] and tagging[] to ignore the unlist exceptions and return all tiddlers with the tag in any case.

Filtered Tagging - Sharing Edition TW

[Springer]

Cool proof-of-concept that reaches much further than my limited model.

What do you think of making sure that the tag-pill INCLUDES the “unlisted” items — but with some special mark (to show their “demotion” from the tag’s “unlist” end)?

The reason I really want something like that is that the tagpill is still the place I want to go to find things that are (in their nature) view templates. Even if they’re not being implemented as such (“disregarded” in my lingo), there’s still the function of the tag — at the tiddler end — which is saying what kind of thing it’s trying to be.

Here’s your tagpill:

Here’s mine:

[Springer]

@TW_Tones

may be a designer wants to loeverage the full view template mechanisium, as added to via multiple plugins and solutions be setup a class of tiddlers that do not display the tags and subtitle. he/she only want to exclude these elements on selected tiddlers. Currently the only way isto build an alternate view template cascade that handles the exception.

I think you’re overstating this limitation: I often make view-templates conditional. They can be conditional on general filter-conditions (tags and such), but also on very ad-hoc things like a field “hide-body” or “hide-tags”.

@TW_Tones

allowing the user to “reorder the edit template” for convienence such as with very long tiddlers place the text editor at the bottom so you can access the fields at the top, but only for large tiddlers. This does not exclude, and may just include (duplicate) the field editor at the top on long tiddlers, or provide an alternative order.

Reordering is indeed harder to do “on the fly” with our current view template. Mostly I think this is fine — I’ve rarely struggled against it. But I’d be curious whether there’s a real point of frustration here.

[Springer]

@nemo

Further, I think a tag tid should be able to selectively include other tids without them asking for it. ie, a tag-override-include list. This extends the flexibility - at the same costs, though I’d expect this would be a more dramatic performance penalty.

My demo initially presented this as a “todo”/aspiration (override-out was going to get a complement called override-in).

I realized, however, that I can’t think of a time I wanted to make a shadow do some positive system-level tag-based role different from what it was designed to do, while I do often want to “mute” a shadow’s effect.

The main two nuissances about rmodfying the tiddler to remove its tags were

1. losing track of whether there were substantive changes to a shadow that only had the tag removed, and
2. losing track of which things in the wiki are designed for a certain purpose (view template, sidebar tab, stylesheet, etc.).

But these issues don’t tend to affect adding tags. Even though adding tags “remotely” is logically symmetrical with removing them remotely, I find the need much less compelling.

Or rather, in every case where I have a compelling reason to include things without modifying them, solutions already tend to rely not on tags but instead on a unilateral list (the story list, favorites plugins, etc.)

[Yaisog]

@Springer

What do you think of making sure that the tag-pill INCLUDES the “unlisted” items

I guess one could modify the tag macro for that. Do you ask if I would find it useful? Probably not (enough). Its usefulness is really only limited to core / shadow functionality and not content tiddlers which I spend most of the time on.

But then you can also make the template for these “tag tiddlers” contain anything you want, like in your OP or the PoC, to include a UI for adding or deleting tiddlers from this list, or reordering.

[TW_Tones]

@Springer

I realized, however, that I can’t think of a time I wanted to make a shadow do some positive system-level tag-based role different from what it was designed to do, while I do often want to “mute” a shadow’s effect.

This need to “mute core tags” is a much needed feature. Its trivial to add another element and within it add a display condition, use list-before or list-after and place it.

For existing core tiddlers with tags like for the View template this is “hard coded in the core” but in plugins or solutions building thier own mechanisiums thay can have mechanisiums that selectivly mute (remove items from a list). It is only the core where this will result in a core tiddler change, and/or complex code, or alternate view template that may clash with other plugins/solutions.

@Yaisog

But then you can also make the template for these “tag tiddlers” contain anything you want, like in your OP or the PoC, to include a UI for adding or deleting tiddlers from this list, or reordering.

This is an importiant point. Many core tags actualy dont yet have “tag tiddlers”, the only issue is they do have a specific name and others may wish to use the same name, because it is a core tag with specific meaning. But overiding current behaviour by creating the tag tiddler (if it does not exist) and editing a field on a tag tiddler is quite a good hackability mechanisium.

However muting system tags in the core is currently a hackability gap, I think it could be ultimatly addressed in the core, after we work it to death first

[Yaisog]

@Springer

What do you think of making sure that the tag-pill INCLUDES the “unlisted” items — but with some special mark (to show their “demotion” from the tag’s “unlist” end)?

This might actually be a pretty good idea when you forget that you have unlisted some item and wonder why the heck it is not showing up…

A non-core-invasive way to do this is to create a tiddler with e.g. this content:

<% if [enlist{!!unlist}tag:raw<currentTiddler>] %>
	<hr>
	<div class="tc-menu-list-item" style="margin-left: 14px;">
		`unlist`ed tiddlers:
	</div>
	<$list filter="[enlist{!!unlist}tag:raw<currentTiddler>]">
		<$transclude $tiddler="$:/core/ui/ListItemTemplate"/>
	</$list>
<% endif %>

and tag it $:/tags/TagDropdown.
This will add a section to the tag dropdown with information about the unlist.
Unfortunately, it will show up above the list of tagging tiddlers. I’d rather have it below, but it works for me.

And yes, I don’t have a sidebar.