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.
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!
Ok, then I didn’t understand what you meant by the following:
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.
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
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.
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?
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.
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:
next to it in tagpillI 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
5 posts were merged into an existing topic: Tag ($:/tags/ViewTemplate) allowed to “disregard” some tag-children
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.
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.
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.
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.
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
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?
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
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
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+1F3F4Although 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;
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;
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
I could say I missspelt there to test you, but I did not. I fixed this by simply renaming those two flag tiddlers.
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
class="tc-drop-down on 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.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;
However, unless I get seriouse objections I will Proceed (part time) to develop this solution further so it could blend into tiddlywiki seemlessly including;
[Edited] it is importiant to note that this mechanisium is;
[/edited]
Please provide further feedback and if you are interested, perhaps try out collaborating with me to build this.