- “I am object X, a member of group Y” is a Tag
- “I am group Y, my members include object X is a Flag
I dont think the flag/tag distinction is nescessary.
I want it to be a tag, with all the rights, responsibilities and functions of a tag. The rest of the system shouldn’t care how the tag was defined.
1 Like
One of my thoughts to explore both here in include and exclude, but also in Flags list field, a list that includes title and Filters.
eg title [[title with spaces]] [tag[system]] where it gets expanded to include all items with the tag system.
This involves not using a list of titles as a list/listed but as a filter.
Then this enables an exception to be included in the list -[prefix[$:/]]
- The issue arrised when an item is listed, included or excluded via a filter, how do you remove one item?, an exclusion obviously?
Simply put, I think it is essential to be destinctive.
Although I would promote flags to be as well handled as tags.
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)
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.
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:
