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

[TW_Tones]

Folks,

This is an idea I recently had that brings together concepts discussed in recent weeks, and may be of particular interest to @etardiff and @Springer as it uses backlinks and works for missing tiddlers, and may be an example of another potential “virtual tiddler”, for want of a better name.

• I write this seeking feedback and ideas.

Background

Using tags is a very useful feature of tiddlywiki, but to modify a tag will make a shadow tiddler into a tiddler, make the tiddler appear in recent lists due to modification (unless timestamps are off) and have other impacts. Adding a tag modifies a list of tags on the tags field of each tiddler, for this reason tags will travel with a tiddler imported or exported and transferred to another wiki.

Plugins that wish to alter tags on system or core tiddlers need to replace that core tiddler or get user interaction to add a tag to that tiddler through a trigger and action. This means core system tiddlers are modified and as a result if more than one plugin or package wish to change a tag there is a strong likely hood of a clash.

Proposal introduce a new mechanism called “flags” (working title)

Let me explain how, by way of a description.

Create a tag called flag. Now any tiddler holding that tag will be what we call a flag. For example lets create a tiddler review-flag, and tag it flag.

Now we provide a mechanism on all tiddlers that allows us to assign a flag to any tiddler.

To find all available flags we can list the tiddlers with the “flag” tag.

Once the user selects one of these flags the “current tiddlers title” is appended to the text field of the selected “flag tiddler”, in this case review-flag (note flag need not be in the name, I use it for clarity)

We also have a mechanism to display existing flags on any tiddler

To test for flags we use the current title, and the backlinks mechanism, to find tiddlers that contain a link to this current title.

• We then test each of the resulting titles to see if they also have the “flag” tag, if they do then this is a flag on this tiddler, and we display that flag tiddler title/caption

High hackability

Plugins and other solutions can include one or more tiddlers with the flag tag using a safe title such as $:/plugin/PSaT/flags/review-flag or psat-review-flag containing a list of titles, existing or not, and can be used with any other plugin or solution without clash.

• For documentation or automation this method allows us to flag titles including system tiddlers without touching them.
• Once in place this flag solution can be used with existing system tags to introduce flagged titles in other places such as the view and edit templates and other cascades. The can be displayed and selected as “review” using the caption, and perhaps a tooltip.
• To support ease of use and using existing knowledge of users we could package a range of filter operators by cloning all tag operators, and make flag operators. Also is[flag] and all[flags]

Issues

If this works well I could see this ultimately, perhaps in 5.4.0 TW @jeremyruston replacing the existing tag process for select tags in the system thus improving hackability.

The step I do not know how to implement is how to remove a title from inside the flag tiddlers. Although I know its possible. I suggest a line for each title so we only find/remove a full line at a time.

• Perhaps we could use a dictionary tiddler allowing deletion and have the key = the title, the value = a description/tooltip.
• This may also need a change to allow a data tiddler to also parse to find backlinks.

Futures

Through this mechanism we gain a new type of tiddler role, the flag tiddler, as we have tag tiddlers.

The fact is a flag can be created and assigned to a title even if it does not exist as a title. This introduces the idea of flagging future titles if and when they come to exist, and then responding to the existence of the title.

I believe this would expose other innovative possibilities.

Regards
Tones

[Scott_Sauyet]

While I find some of this interesting, and it strikes me as relatively easy to implement (especially if it is built on something like the GenericTagFields plugin), I’m not sure how widely useful it would be. I’m absolutely against using this technique to replace the current tag mechanism. I can see some possibilities of complementing the current mechanism with it though.

I would be concerned that a tiddler I use on one wiki, when dragged to a second one, could have radically different behavior, because it doesn’t take its flags with it. Obviously there are already some differences – different ViewTemplates applied, for instance – but this, I think would be a larger issue. We’re spreading the behavior of our tiddlers across the whole wiki. I’d hate the loss of granularity.

---

@TW_Tones

The step I do not know how to implement is how to remove a title from inside the flag tiddlers. Although I know its possible. I suggest a line for each title so we only find/remove a full line at a time.

You can do that with ActionListopsWidget:

<$let tid="Tiddler C">
<$button>Remove "<<tid>>" from review
<$action-listops $tiddler="review-flag" $field="text" $subfilter=`-[[$(tid)$]]`/>
</$button>
</$let>

You can try it with this: RemoveFlag.json (1.4 KB). Open Tiddler C, review-flag, and Remove Flag Demo. Click the button in the last one and see the changes in the first two.

[TW_Tones]

@Scott_Sauyet

I’m absolutely against using this technique to replace the current tag mechanism

No one suggested it replace anything, it is another way to use tiddlywiki, another affordance.

@Scott_Sauyet

I would be concerned that a tiddler I use on one wiki, when dragged to a second one, could have radically different behavior, because it doesn’t take its flags with it.

This is actually the point, there are times where this is exactly what we want. Without delving into examples I have seen a range of questions and concerns which such a mechanism would solve.

• For example Imagin a document with steps. Transferring those steps to another wiki may resent their done flag, and you get to do them again for that new wiki.

If part of a package/plugin or bundle you would also include the flag tiddler and its titles there in. There are many examples of where transferring to another wiki is not a single tiddler affair.

@Scott_Sauyet

You can do that with ActionListopsWidget:

Thanks I will test. Although my late suggestion to use a data tiddler may be superior, because we can have a description even before a title is turned into a tiddler.

More futures

This mechanisium actualy points to a number of innovative uses I have in my head (read my mind if you can) , and whilst I proposed an out of the box use to make “no touch tiddler flags” the method could be used to achive more if further generalised. ie the mechanisium can be coopted for more than flags.

• To do, this rather than clone tags to flags using the alternative approach a more generic leveraging of the backlinks mechanisium to return the title of a tiddler containing that backlink and meeting a condition like tag[flag].
• The current backlinks operator does not use its parameter, so it could be used as a subfilter or something similar, and backlinks currently returns the title of the tiddler(s) containing the backlink but it could allow use to specify another field of that tiddler, a bit like the lookup operator.

[pmario]

There already is a mechanism, that allows us to connect “flags” to shadow tiddlers, without modifying them.

Currently it is used with the visibility system of toolbar buttons and also system fields. So we can “show” and “hide” elements, without modifying them.

eg: $:/config/EditorToolbarButtons/Visibility/$:/core/ui/EditorToolbar/heading-4 is “hidden” by default.

The filter, that can deal with those values, uses the lookup-operator. So if you search for lookup, to see where and how it is used at the moment.

Everything you describe can be done already.

[TW_Tones]

Thanks Mario, I will have a look, although I don’t think that is a mechanism I have missed. I can’t see how it resembles my flag idea.

although on reflection perhaps the list of titles in a flag tiddler belong in a list field.

I hope to make the flags as easy to use as tags.

[stobot]

That’s so interesting @pmario , I’ve read the document for ‘lookup’ many times before (because it has such a simple, useful sounding name) but could never understand why I’d ever need such a thing. This makes a lot more sense now!

[Scott_Sauyet]

@TW_Tones

@Scott_Sauyet

I’m absolutely against using this technique to replace the current tag mechanism

No one suggested it replace anything, it is another way to use tiddlywiki, another affordance.

Ok, then I didn’t understand what you meant by the following:

@TW_Tones

If this works well I could see this ultimately, perhaps in 5.4.0 TW @jeremyruston replacing the existing tag process for select tags in the system thus improving hackability.

If you’re not proposing a replacement, I’m much less opposed. I’m not sure I feel any great need for it, although I have occasionally kept tiddlers containing a list of titles, for similar purposes. But it also sounds like a reasonable plugin. I’d need to see more specific uses before I would even consider asking for it to go in the core.

[Springer]

@TW_Tones

@Scott_Sauyet

I’m absolutely against using this technique to replace the current tag mechanism

No one suggested it replace anything, it is another way to use tiddlywiki, another affordance.

I agree with @TW_Tones that it would be great to think in a big-picture way about kinds of flags/marks that don’t live in the tiddler.

I think we have a model for this in various “Favorites” plugins (here’s just one older example, by @Mohammad ) These plugins allow maintaining a list without “touching” the tiddler in question, and often have a visible element showing in the tiddler itself (on the toolbar) that makes the status look like it belongs to the tiddler itself.

Although I wouldn’t like to replace tags, I do feel ambivalent every time I modify a shadow tiddler just by adding or subtracting a tag!

One thing I might experiment with is this: imagine a tag’s home tiddler (the tiddler that has the list field, tagpill color, etc.) being able to host a manual override of includes and excludes. Then I could effectively take $:/tags/ViewTemplate off of $:/core/ui/ViewTemplate/subtitle without modifying it. (That is, the tag itself is not removed, but the tag home tiddler keeps an override-out list, and the actual $:/core/ui/ViewTemplate is modified to respect that list.)

Of course, this kind of modification, if undertaken wholesale would mean a pretty major refactoring of how tags work, and might seem overcomplicated. Still, I might try a proof-of-concept just for $:/tags/ViewTemplate — the most basic case of a place where I often want a touchless bypass of the existing tag.

Edit to Add: proof of concept at Quick-Demo

[nemo]

@TW_Tones

this case review-flag (note flag need not be in the name, I use it for clarity)

uh… the overuse of “flag” I find detracts from clarity here. “flag” is being overloaded with multiple uses - that one of them is prefixed with “review-” doesn’t really help the overload to me.

@Springer

I do feel ambivalent every time I modify a shadow tiddler just by adding or subtracting a tag!

ambivalent? Or Anxious? Because I feel mildly anxious when a shadow tid is modified simply due to tag updating, and for that reason alone I find this proposal very interesting.

I wonder if the whole new “flag” terminology is needed though. Why not just have the existing tag tid have a “tagging” field?

[Springer]

@nemo

Why not just have the existing tag tid have a “tagging” field?

I agree that the place to do this is in the tiddler for the tag (the tag’s “home” tiddler).

But I think tagging is not the right name for the field!

That’s because tagging[] is already a filter operator, and the solution here would explicitly involve NOT literally tagging (or untagging) the tiddler in question, but simulating some behavior that is ordinarily associated with having (or not having) a tag.

Overriding behavior associated with $:/tags/ViewTemplate — while not removing the tag — is the clearest use-case, so that’s the need I’ve developed a proof-of-concept for.

The rest of this post distracts from this thread, so I'll tuck it into details

I’m not thrilled with my fieldname choice, but I tentatively chose override-out as the fieldname, such that if $:/tags/ViewTemplate (the tiddler for the tag) has something listed in its override-out field, then the wiki is designed to treat it as excluded from the normal effects of that tag except:

• it still actually has the $:/tags/ViewTemplate tag, BUT the tiddlers tag-wrapper (in view mode) shows that tag as overridden.
• It still appears in the tag’s dropdown, BUT with next to it in tagpill

I welcome feedback!

Here’s a screenshot of current state. Note that the tiddler is not showing its subtitle. But in fact the subtitle viewtemplate is still tagged as viewtemplate at its own end. But under the tag tiddler, it’s listed in that override-out field:

Here’s the separate thread on “disregarding” tag-children from the tag-home end of the relation: Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children

[pmario]

@Springer

One thing I might experiment with is this: imagine a tag’s home tiddler (the tiddler that has the list field, tagpill color, etc.) being able to host a manual override of includes and excludes. Then I could take $:/tags/ViewTemplate off of $:/core/ui/ViewTemplate/subtitle without modifying it.

This can only be done, if the core templates, that use those tags add additional logic that uses “flags” to disable those tags.

[Springer]

@pmario

This can only be done, if the core templates, that use those tags add additional logic that uses “flags” to disable those tags.

Perhaps you’re responding to earlier post. I do have a full explanation at the demo — which of course includes tinkering with the core — to partially override (virtually exclude tiddlers from) the $:/tags/ViewTemplate tag.

As I note there, the difficulty with any solution like this is: We need to figure out which core features “care” about the tag, and get them to respect this override (I think that’s the point you were also making, yes?) Edit to add: Also we’d need to create good visual/explanatory breadcrumbs, so that there’s no confusion about whether/how the tag includes the tiddler: we need modification to how tagpills display, how tag-wrapper area in the tiddler itself displays, etc.

So, this is only a narrow proof of concept, and it doesn’t generalize well. With view templates in particular, though, I think I may actually adopt it on a few wikis!

It was always really stressful to toggle a view template off, not having a neat place where it could be toggled back on.

My old workaround was to have a manual process whereby every time I removed a $:/tags/ViewTemplate tag, I manually added a $:/tags/ViewTemplate/OFF tag, just so that I could keep track of the various things that were designed as view templates (in shadow, plugin, or custom templates of my own that I was needing to suppress temporarily). (Alternately, I tried perpetually tinkering with the Toggle! solution by @DaveGifford.)

[nemo]

@Springer

But I think tagging is not the right name for the field!

Good point, and 100% agree now you’ve pointed that out.

@Springer

I’m not thrilled with my fieldname choice, but I tentatively chose override-out

How about is-tagging or tagging-list? Both feel reasonably obvious to read (though if the proposed fields-as-tid’s/links proposal happens, then any field name for this would get a nice tooltip explaining). “tagging-list” is a nod to the built-in “list” field - I’m not sure if that would be a help or a hindrance to clarity here (I dont understand the way lists are built and used sufficiently, esp the interactions of list list-before and list-after. But that’s too much topic divergence for here)

[TW_Tones]

@nemo

uh… the overuse of “flag” I find detracts from clarity here. “flag” is being overloaded with multiple uses - that one of them is prefixed with “review-” doesn’t really help the overload to me.

The point being a flag is an indicator, as a tag is an indicator of membership of a set. As I said this is a “working title” however the destinction is essential, I dont know how you would do without.

• In this example it is not that I prefixed flag with review-, but that I suffixed review with -flag to call out that title as being a flag. Just as one may tagname-tag. It is used here more to keep clarity in examples and the discussion, not what you would nessasarily implement.

@nemo

I wonder if the whole new “flag” terminology is needed though. Why not just have the existing tag tid have a “tagging” field?

This is an idea worth investigating including @Springer’s idea of blending into the tag concept.

@Springer

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.

Exactly what I would like to address.

@Springer

to partially override (virtually exclude tiddlers from) the $:/tags/ViewTemplate tag.

I have spent a lot of time in this realm of “problems” enabling exceptions, I have more often that not maintained the $:/tags/ViewTemplate and within that made my code selective. Thus avoiding core changes except the $:/tags/ViewTemplate tag itself.

• Have we made this topic into two rather than one focused issue directly related to the topic?

Here is an example of how I may use my concept of a flag.

Using no touch flags I can create a few flags including “Story, ViewTemplate, Edit Template” and flag the shadow tiddlers involved in each of these, in the order they appear, in the process involved in each of these tiddlywiki “processes” so new and expert users alike can “follow the trail” of tiddlers used in such processes, but reviewing the tiddlers that share a flag. One or more flags on the same tiddler are permissable.

• These flags (the tiddlers defining the flag) can be imported to any wiki (with flags support) and guide the wiki user without touching (modifying) any system tiddler.

I actualy have quitre a deep understanding of these tiddlywiki structures such as "Story, ViewTemplate, Edit Template and cascades etc… However it can still demand a high cognative load to follow such paths searching for how something has being done or to modify it. As a result I would like a flag solution to support this.

• Ultimatly it should be in the core so it is a common mechanisium we can all use.

Whatever the outcome of this conversation I expect I will make a demo and seek support and comment from you all. I have maintained an open mind on all your feedback, but to be honest I have not yet found a reason to deviate far from the original concept. I hope an example / demonstration will prove this to many of you.

A resent trigger to revisit the flags concept Edit tiddler shortcut - #12 by TW_Tones

[nemo]

@TW_Tones

it is not that I prefixed flag with review-, but that I suffixed review with -flag to call out that title as being a flag.

A difference without distinction here. My point is that I would have found it quicker to understand what the difference between “flag” and “review” was, without having the word “flag” show up again on the review side. Sometimes clarity isn’t achieved by over-explaining, it’s achieved by clear distinction

@Springer

One other connection here: I’d like to offer a shout-out to @DaveGifford, whose “Toggle” solution,

Oh, I’d not seen that before, I like the effect and will have to look into it more

@TW_Tones

Have we made this topic into two rather than one focused issue directly related to the topic?

I think so, though if they’re the two topics I think they are, they’re still very related, and looking at my previous reply to @Springer I think I had not picked up on the topic branching from adding tags without touch vs overriding tags

In one case, it’s about adding a tag to a tid (which doesn’t have it) without updating that tid

in the other it’s about removing a tag from a tid (which already has it), also without updating that tid. And also about where that removal applies.

Is that the same page others are on, or have I topic diverged differently myself?

[TW_Tones]

Relating to Tags removal from shadows

@pmario

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.

Something that would help this would be perhaps a tab in the info drop down that indicated which fields if anything, on an overridden tiddler, differ from the shadow. Or in this case when only the tags are different compared to the shadow tiddler. noteThis is available in the editor preview excluding the fields

• I or someone could make an option on the tag dropdown, such as in my reimagine tags solution, that could present an option when this is the case, “remove tag and reset to show tiddler”.
  • Similarly a filter pill version
• Lets make a simple to use function that returns the tag name when and if this is the case.
  • It need only appear on the last nonstandard tag on the tiddler.
  • What about when the only difference is a tag was removed?

In many ways an easy way to get easy to determine differences between shadows and the modified non-shadow, that can be part of the view mode interactive UI would be very helpful

On the idea of no touch flags

I think to start I will create a demo, as mentioned earlier. For now I may restrain flags to being displayed in the subtitle with an optional colored flag, optional short name (caption or title), and a description on mouse over to start.

• Triangular Flag on Post — U+1F6A9
• Chequered Flag — U+1F3C1
• White Flag — U+1F3F3
• Black Flag — U+1F3F4

Although I would love to have a text field full of readable titles, one for each line, I will start by adding titles to the list field of the flag tiddler.

[Update] I have completed 80% of a demo, but I think I need to;

• not use the list field in flag tiddlers, because if they are also tag tiddlers the list field will be compromised. As a result I plan to change all my code so far (very little needed) to use the flagged-list fieldname instead.
  • The same could be said for other flag fields like color or do we just use the single color field and deal with the compromise?
• should I assist users by providing a two click method to make the current tiddler a flag as well? this could cause flags to proliferate.

[TW_Tones]

OK, I have made a demo of my idea. It is implemented through the submenu on tiddlers and allows any tiddler defined as a flag by tagging it as a flag.

The features will still need to be extended, but is a sufficent demo of the key concept.

https://flags.tiddlyhost.com

have we solved this oembed tags issue (above)?

Planned Improvements;

• List all tiddlers with a given flag when clicking on a flag like a tag tiddler
• Add the ability to add items to the flag dropdown
• Generate operators for flags just as we have for tags.

[Springer]

It will take me a while to wrap my head around this approach.

I was trying for a while to figure out where the todo flag “lives” or how to apply it … (but eventually realized those mini-tagpills are not related to the flag solution!).

Currently it seems there’s no easy affordance for removing a flag, besides editing the list (in the flag tiddler) and removing that tiddler from the list?

(+Minor note: there’s a letter missing from “ViewTempate” and “EditTempate” which want to be “ViewTemplate” and “EditTemplate”)

[nemo]

@Springer

I was trying for a while to figure out where the todo flag “lives” or how to apply it … (but eventually realized those mini-tagpills are not related to the flag solution).

glad I wasn’t the only one who found that a distraction.

@TW_Tones maybe this would be better demonstrated on top of an empty.html to ensure we’ve got a common baseline of behaviour to then consider what this changes.