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

Developers
, ,
#1

This idea was initially shared in @TW_Tones thread on flags (variation on tags).

details: Why this new thread? / divergences from that flag idea

I want to let that thread have its own identity, because my variation may be a distraction from the flags vision, though we share the common problem of wanting to be able to “include/exclude” in a tag-like way, without actually modifying the tiddler.

I think wholesale external lists are important — most favorites plugins, and even the $:/StoryList, are great models of lists managed external to the tiddlers so listed. The idea of letting a tag still basically work as it does — but with a caveat — is different.

I’ve been working for a while on tagname nodes (as well as fieldname nodes) as places in the story river where helpful things automatically appear.

Meanwhile, actual tagname tiddlers (as well as fieldname tiddlers) can be harnessed for doing real work…

HYPOTHESIS: What if the tag’s home tiddler could “unlist” or “demote” some of its tag children, without modifying them? What if a tiddler’s claim to a tag could be… blocked? disregarded?

DEMO: I’ve set up a demo for how this would work with a disregard-list field at $:/tags/ViewTemplate. This approach is not easily generalizable to other tags (at least with my wikitext-only skills!), because a solution requires figuring out where else in the wiki the tag matters, and setting up conditional bypass/signpost behavior in each of those locations. A number of core tiddlers have been tweaked in this proof-of-concept solution.

All the relevent tiddlers carry the tag-override-solution tag, so you can try dragging that tag to another wiki.

screenshot from tag-batch ported to tw-com

image
image2012×1414 400 KB

WHY: I find a strong use-case for this solution because…

  • I often want to toggle view template elements on and off, but without losing track of which tiddlers belong in the “view template” category — which tiddlers are designed to function that way, and might want that tag re-added. (I tried a practice of replacing $:/tags/ViewTemplate with $:/tags/ViewTemplate/OFF but it was a nuissance.)
  • Toggling the actual tag off (and on) can create confusion whether shadow templates (from core or 3rd-party plugins) had actually been substantively modified. When I update plugins, the process is slowed by going through and checking which of my shadow-override tiddlers were nothing more than removing the $:/tags/ViewTemplate tag from subtiddlers (and maybe putting it back on, without taking time to check whether it was safe to delete-to-restore-shadow).

OBSERVATION: Tagging is already a relationship managed in complex hybrid ways — it’s up to a tiddler whether it has a tag… But list-order is basically up to the tag tiddler… except … tiddlers can jockey for position with their own list-before and list-after fields (but… those fields can be silently removed from the tag tiddler end, if the tag’s list field is modified via tagpill…). Letting the tag’s home tiddler have a place to register a “veto” or “suspension” authority over its tag “children” is a natural development to explore.

CAVEAT: It would be a very heavy lift to generalize any such solution (at least without tinkering with javascript?), because of how deeply the core leans on the simplicity of unilateral (tiddler-side) “claiming” of tag status. Still, seeing what tag-side refusal looks like and feels like in practice, for this one tag, may help us think creatively about what kinds of tag-like-relations we desire.

Comments welcome!

1 Like
No touch tags - or flags on tiddlers without editing or changing the tiddler
No touch tags - or flags on tiddlers without editing or changing the tiddler
No touch tags - or flags on tiddlers without editing or changing the tiddler
#2

Wouldn’t it be easier to make this a general feature of how tags work and modify the tag[] and tagging[] filters correspondingly instead of modifying all those system tiddlers?

#3

Perhaps. I assume this would require javascript, though, which is not in my toolkit.

#4

I think I’m with @Yaisog on this. And then I’d certainly want [tag[foo]] to behave back-compatible and [tag:<something>[foo]] to work with the new regime.

FWIW, I use flags and labels stored in list fields, though they are stored in the tiddlers they pertain to, exactly the same as tags are. OTOH, I use addenda tiddlers stored externally, *-notes, *-info, *-notices, *-questions, etc., all of which are displayed in the associated tiddlers as tabs.

Honestly, I don’t have an opinion as to which is better, though the addenda do prove helpful implemented as independent tiddlers.

#5

Of course it would be easier if this could be implemented in a wholesale way!

So, do you share my impression that this approach would require javascript? (I’d also love to hear confirmation of that from @Yaisog). I don’t see how else all the stuff that looks for the $:/tags/ViewTemplate tag could be (automatically) convinced to disregard tiddlers that do tag it, but which are listed in something like a disregard-list field from the tag tiddler’s end of the relation.

But on a more substantive note:

Also, it really is not ideal to make all other tiddlers simply behave as if “disregard-list” tiddlers simply LACK the tag. The tag pill should still show the “suspended” ones as “claiming” the tag — belonging to that functional category — while also being somehow marked as “demoted” or “muted” from the tag end.

Having this “trying-to-tag” status visible is part of the point, because the $:/tags/ViewTemplate tag (for example, but also lots of other core and plugin tags) currently serves TWO purposes:

  1. to show what kind of purpose something (a template or cascade condition, etc.) was designed for, AND
  2. to make it actually serve that purpose.

If “disregarding” the tag from the parent-side simply makes it as though the various would-be tag-children never even had that tag at all — from all angles of view in the wiki! — then it wouldn’t be as powerful as the set of affordances I’m modeling in the demo, where (1) and (2) are allowed to come apart.

#6

I’m not sure whether you checked out the demo, but this approach does absolutely nothing to inhibit backward-compatibility.

Unless someone somehow has a field called disregard-list on tiddlers that happen to be tag home tiddlers (listing tiddlers that have that tag), none of the tweaks I’ve made will alter how a wiki behaves, until someone uses the tag-side mechanism (disregard-list field) to mute tag-children.

[tag:<something>[foo]]

Umm, as far as I know there’s no suffix to the tag operator besides the strict flag. Is there some development here that I should know about? (Or is it: you’re hoping whatever we’d all do next (in terms of expanding the power of tags) would include the capacity to expand to fields other than tags that could be marked so as to behave like tags?)

#7

One other connection here: I’d like to offer a shout-out to @DaveGifford, whose “Toggle” solution, years ago, was my first way to dynamically hide/unhide various view template elements from the sidebar.

Unfortunately, that solution relied on a manual setup for each such element. So that if I added a custom “comments” view template to my wiki, it wouldn’t be part of the “Toggle!” sidebar until I went and hard-coded it in as a thing that could toggle on and off.

And that solution — helpful as it was! — did actually modify the template tiddlers by toggling the presence of the $:/tags/ViewTemplate tag. So if I removed and then re-added the tag to the subtitle view template, the tiddler would be a non-shadow… even if the toggling restored exactly its original shadow contents.

So I am curious whether @DaveGifford agrees that what I’ve sketched out here in proof-of-concept is effectively a good successor-solution to Toggle!

(Toggle also toggles the system tags on edit template and sidebar elements. I haven’t implemented tag-overrides for these yet, though the same principles would apply.)

1 Like
No touch tags - or flags on tiddlers without editing or changing the tiddler
No touch tags - or flags on tiddlers without editing or changing the tiddler
No touch tags - or flags on tiddlers without editing or changing the tiddler
#8

Anything would be better than Toggle, for sure. I knew others could do it way better than me, but I had to figure out some way to customize things, and mixed bits and pieces together from replies I got at the time, a homemade brew that I didn’t understand at the time and probably still don’t. Glad you got some use out of it, and then got inspiration from it to make something of your own!

2 Likes
#9

@Springer

Not a fan of override-out, I’m afraid. It’s carrying baggage from the discussion here that isn’t reflected in its name.

Maybe one of these?

tags-disabled / disabled-tags

tags-overidden / overidden-tags

detagged

sent-to-siberia :crazy_face:

#10

The recommended way to “reset” overwritten shadow tiddlers is to delete the system-tiddler. So the shadow will take over again. [is[tiddler]is[shadow]] allows us to find out if a tiddler is also a shadow, so it can be deleted, if needed.

No touch tags - or flags on tiddlers without editing or changing the tiddler
#11

Sure, that’s the best way if what one wants is: to restore the shadow. But my goal in these moments is not “to restore to shadow” but rather to re-add the view-template tag. (And that was @DaveGifford’s goal with Toggle also, since he couldn’t assume users would have made no substantive change to the template.)

At the time of wanting the subtitle (or Shiraz sticky-footer template, or whatever) to display again, I may not recall whether removing the tag was the only change I had made. Confirming this requires a separate step of getting into edit mode and examining the compare-diff preview and checking for added field content etc., and these extra steps are a distraction from my workflow. Since I often do substantively modify shadow templates (but also, just as often, have made no change beyond removing the view-template tag), it’s a minor nuisance that taking the tag off messes with the shadow state.

Hence my desire — for the $:/tags/ViewTemplate tag in particular — to find a way to effectively “demote” or “unlist” the tagged (template) tiddlers “from the tag end” of the relationship, as it were.

#12

Agreed! I’ve renamed the field disregard-list … because it’s useful to see that it’s a list field, and because it’s not really “untagging” but rather allowing the main system-level effect of the tag to be (for the basic functional purpose) muted.

My worry about all of these (and I did consider things like this) is that the plural might imply that the function of these and see them as potentially working in the child-tiddler (naming the tags to be overridden/disabled). I want it to be clear that what’s being disregarded is the tag-child tiddlers that are listed, in the tagname tiddler.

If we want to use the word tag in this list-field name, I’d want something that comes across as: suppress this tag for…

#13

Better. Or even just disregarded – it’s placed in the tag-tiddler which is all about tags and tagging so I think the suffix “-list” is possibly unnecessary.

I brainstormed this with Marvin (my ChatGPT’s persona). In all cases, the suffix “-tags” can probably be dropped…

withheld-tags
suspended-tags
muted-tags
ghosted-tags
deferred-tags
excluded-tags
inactive-tags
unlisted-tags
bypassed-tags
quiet-tags

Marvin also suggested shadow-tags which was kinda cool but since “shadow” has a clear meaning in TW, must be considered a poor choice for this.

My fav(s)? withheld-tags, ghosted-tags, muted-tags

#14

@Springer here is a quick responce to the concept as a whole, independent of my Flag work.

I have actualy found a need to handle exceptions as well to a tag list. This led me to build a quite sophisticated solution to explore this myself and I have a way to add exceptions to the view template tags as an example. This is part of a class of issues with dealing with the hackability of tiddlywikis core processes, without reverting to new layout or viewtemplate cascades that are 99% unchanged.

It is my view here that the problem needs a good “code pattern” for designing solutions that can use inclusions and exclusions to a list, initialy established with tags.

However one clear conclusion is that the core needs improving in a number of its tag driven solutions to permit the inclusion or exclusion dynamicaly.

  • An example 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.
  • Another type of exception is 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.
  • A key way now to achive this using finctions, or variables containing a subfilter, even if the setting is obtained from the current tiddler or a global definition. By making inclusion and exclusion lists available via a variable/function gives a useful abstraction layer rather than direct tiddler/field references, that can be localy overidden.

Speculation

Given my work on the flag concept, I am tempted to ask if we could invent another mechanisium that lends itself to achiving what you want without interfearing with the current tag mechanisum. Although once established there may be an argument to move the tag driven UI to such an alternate mechanisium.

The reason I am thinking this is there has being a number of times when I have thought more features for handling lists/sets would be helpful to users and designers of tiddlywiki as a whole. Such lists/sets would be able to be used with common set manipulations such as union. We have the operators to do this already. We just need to promote appropriate “code patterns” to make this easier to follow.

Just as I have looked at designing flags, or a no touch way to categorising tiddlers, I could see the idea of adding tools to support and design a new “set handling mechanisium” that includes “include and exception handling”, even if it lays on top of tags.

There is also a “natural cascade” that we could bring to the for that determins a value in the following order;

  • An overidding value set in the tiddlywiki script
  • An overidding value set in a currentTiddler field
  • An overidding value set in the view or edit cascade
  • An overidding value set in a global setting tiddler
    • And a default when not avialble.

Imagin having this available for your include and exclude lists/sets. They can me modified at any appropriate level.

#15

the more I think about this and Flags, the more I think I just want tags but with additional flexibility on how they’re set or excluded.

Currently a tid’s tags are set by it’s own tags: field. Nice and simple.

A tag tid being able to selectively deny it’s use as a tag to other tids via a tag-override-exclude list (or whatever it ends up being called) as this thread proposes, adds nice flexibility, at the cost of some core code changes, probably a little performance cost in the core, and the simplicity of finding how any given tag is set.

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.

I will note my thinking on the latter is very much influenced by nagios, where objects (servers, services, contacts, etc) can be members of a group. That group membership can be defined with the object “I am object X, a member of group Y”, or it can be defined by the group “I am group Y, my members include object X”. The end result is the same in terms of group membership, it only makes a difference to management of membership.

#16
  • “I am object X, a member of group Y” is a Tag
  • “I am group Y, my members include object X is a Flag
#17

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
#18

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?
#19

Simply put, I think it is essential to be destinctive.

Although I would promote flags to be as well handled as tags.

#20

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)