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

Developers
, ,
#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)

#21

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.
No touch tags - or flags on tiddlers without editing or changing the tiddler
#22

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

#23

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 :+1:

#24

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?