Reminder: This is about tags and tagging and a proposed evolution thereof. Flags are being discussed elsewhere.
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 
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?
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. 
I think, both ideas are interesting and valid on their own. They differ in the level, where the need to be implemented.
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.
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.
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 …
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]]
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.
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.
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.
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:
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”.
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.
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
- losing track of whether there were substantive changes to a shadow that only had the tag removed, and
- 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.)
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.
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.
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 
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. 
1 Like
Looking at this example really makes me think the correct term is delisted not unlisted. However you are listing it, all be it via a special view.
- delist suggests its listed and you are stoping it to be listed.
- unlist suggests its permanently removed from the list.
Although I have not participated 100% in this conversation (sorry) I would favor a field in any tag field called delist-filter where in the logic can determin when and if to delist something. For example what it we wanted to hide the subtitle on tag tiddlers, we may place a filter;
-[all[current]is[tag]then[$:/tags/ViewTemplate/Subtitle]] in the tag tiddler $:/tags/ViewTemplate this would delist only $:/tags/ViewTemplate/Subtitle on $:/tags/ViewTemplate
- Critical here is its almost trivial to be drawn to $:/tags/ViewTemplate if something so tagged is not being displayed, and here we find it is delisted only of tag tiddlers.
If this method (or another) was implimented it would be trivial to add something to the tag pill to inform the user of the fact there is a delist filter present. For example to my reimagin tags solution. One would only need to click on the tag pill to be informed a delist filter is present.
There is another way to do this and I will give it some thought. the idea in the above example is to add the delist-filter to $:/tags/ViewTemplate/Subtitle and have a fieldname of $:/tags/ViewTemplate/
- We can then see which tag the current tiddler is delisted from (allowing multiple) and the conditions it is delisted.
I love this form of colaboration folks