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.)
Good point, and 100% agree now you’ve pointed that 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)
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.
This is an idea worth investigating including @Springer’s idea of blending into the tag concept.
Exactly what I would like to address.
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
1 Like
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
Oh, I’d not seen that before, I like the effect and will have to look into it more
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?
1 Like
Relating to Tags removal from shadows
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.
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.
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.
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”)
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.
@nemo, I agree that my proposal was pulling in too different a direction from what @TW_Tones meant to suggest (though we obviously overlap quite a bit in identifying the problems we’re tackling!).
So I’ve moved the bulk of my demo-linking and discussion to a separate thread, and I’ve tried to port over (to that thread) the reply-posts that were most directly engaged with my solution.
My solution is best described as “tag gets a disregard-list field to “mute” tag-children — suppressing them from the tag-end of the relation, without modifying the tag-children”.
Thanks @Springer for your feed back, I finished later at night so left some gaps.
Sorry they were from reimagin tags. I removed them from the demos subtitle to assist
Once a flag is set on a tiddler mouse over that flag advises to remove use ctrl-Click
- This is not cast in stone
I could say I missspelt there to test you, but I did not. I fixed this by simply renaming those two flag tiddlers.
- This works without relink or any other games as flags names have no other special relationship.
Perhaps but I expect to return regularly to update it depending on your feedback. I have tidies it up a little. Feel free to provide specific improvements you would like to see.
Its just a common plugin I use when writting code and I can save changes but leave the tiddler in edit mode. It places extra buttons on the editor. Should be core options, at least in my view.
Great, I have some feedback which would have complicated things for me, in this discussion thread.
Matters arrising
- I used the
class="tc-drop-downon the drop down but this is insufficent to replicate other dropdowns. I need to know more of the css to add padding and stop text being gray, is this documented anywhere?, if not it should be. Including for other core UI elements so tiddlywiki leads by example. - I would realy like to know how to do the oembed settings for tiddlyhost wikis to support rich links to such wikis. I am confident its doable.
What is importiant is I belive I have demoed the Proof of concept for the flag idea. In some ways it is trivial to implement and very effective. Of course I will improve the solution as it stands such as;
- Listing tiddlers also with the same flag, when clicking on a specific flag
- Adding icon, color and description options to flag tiddlers
- Making the current tiddler a flag
- move list to flag-list
However, unless I get seriouse objections I will Proceed (part time) to develop this solution further so it could blend into tiddlywiki seemlessly including;
- No need to use the flag tag (eg add a flag-list field to make a flag tiddler)
- A full suite of flag “filter operators”
- Additional optional UI elements for handling flags similar to the tag editor and display
- Enhance the flag dropdowns to work like the tag pill dropdown, including provisioning the adition of items (by tag) to that dropdown list, for hackability like reimagin tags makes use of.
[Edited] it is importiant to note that this mechanisium is;
- friendly to missing tiddlers, such that you can “flag” a title that does not exist
- I plan to add an example of this to the Demo - system tags
- Is not leveraging the backlinks mechanisium but something similar could
[/edited]
Please provide further feedback and if you are interested, perhaps try out collaborating with me to build this.
You should create an issue at Github about this one, so it will not be forgotten
1 Like
Sure, but I try to have an answer before I raise an issue. I need an answer for my current wiki.
Quoting from Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children - #21 by TW_Tones but to here because this topic seems more suited
This is where I’m confused. If it’s as feature-rich but a different code set, then isn’t it parallel work? What benefit does it serve? Wouldn’t every plugin that enriches tags not enrich flags, so to keep the same richness there would forever be parallel work?
otoh, if it’s just a different mechanism to tag something, then I think a separate name is confusing.
Based on discussions so far and this topic title, the first of these I’d call “flags” and the second I’d call “no touch tags” - only to clarify during discussions to distinguish from the current tagging method, though maybe “tag assignments” or something would be even better)
For a moment understand I use “flag” to differentiate it from the current tag system. It however has the advantage of differing by one letter. Especially If I build filter operators.
It seems you don’t sufficiently grasp the enormous difference between a tag which one or more exist on each and every tiddler with that tag, and specifically when added to a shadow tiddler edits each and every tiddler. Making it a tiddler.
- In the case of core tiddlers this also overrides the default for everything else in the tiddler and effectivly demands twice the bytes.
- It becomes difficult to determine if the tiddler has changed only its tags. or something less trivial, eg code changes.
- Currently to transfer “tag tiddlers” between wikis it trivial, unless you want to transfer which titles it tags, but not transfer the actual tiddlers. So it is no longer trivial.
Flags on the other hand can be used to mark any tiddler, yes functionally like a tag, however the information about which tiddlers have a flag is retained within the flag tiddlers themself, not on the items which are flagged. We can only see that a flag exists on a tiddler by adding something to the view template, because unlike tags they are not contained within a field on each tiddler.
- The disadvantages of tags are avoided with flags, the tiddler need not be edited, especially good when marking tiddlers in the plugin or core as only shadow tiddlers.
- The flag tiddler can be dragged and dropped to another wiki, which if it handles flags, will immediately flag all relevant tiddlers if opened in the story missing or otherwise.
- You can not tag a missing tiddler.
- You can flag a missing tiddler. Have a look at the system tags
tiddler to see this in action. It has practical uses.
So I would be reluctant to call them no-touch tags. They are fundamentally different even though they can be used in similar ways to categorise tiddlers, just as you may use fields on tiddlers, such as “keywords”, to do the same thing. For this reason I would also differentiate them using flag icons/symbols.
Have you seen my filter pills solution?. This too looks somewhat like tags but is driven by filters and again is substantially different as it is effectively dynamic.
- I could have used the filter in the flags solution, on a filter pill, but I need the flag list and add/remove tools on tiddlers as well.
A conceptually different method needs to be differentiated from similar ones lest its difference be overlooked.
Post script.
Implied but not stated is unlike tags which are used to drive much of the core and UI flags serve a different function and may be less likely to suffer from “pollution”, when the are too many flags to be practical, as sometimes occurs with tags. This is a good reason for them to exist in the subtitle and not as if they were tags and using a “like” tag pill.
[Edited]
I was going to use the backlinks operator here, however I ended using the listed operator, as a result we can look in the info tabs to see the “listed” items. Such that we can say that flats are effectively “titles listed”
…
Everything you describe there (overriding core tids or creating shadow, lack of clarity on what has changed, transferring a tag set between wikis) I understand.
That’s the bit I disagree. Yes there is a difference in the mechanism behind the scenes in how a tid ends up tagged, but apart from the “I choose to be tagged” vs “I was tagged regardless” difference, I seems what you are describing is otherwise fundamentally the same.
I had not. I’ve found what I assume is it at https://bookmarklets.tiddlyhost.com/, but it’s not clear what it does or how it works.
That’s a good point. The overlap of tags that drive the UI, and tags that users allocate to organise their content structure - that feels like it could be worth exploring.
(I have a vague recollection that classic TW had a system whereby tags could be hidden from normal display, thus avoiding visual pollution. I haven’t noticed the same in TW5, though I’ve not looked either, and feels like it could cause different confusion too - the clarity of tags is useful!)