It seems we have 99% of this solution, as I have seen before we need to push hard to do this last 1%
Yes, I now favor disregard-filter
The key value of introducing something like the [disregard.filter[$:/tags/ViewTemplate]] which needs a global custom operator is it can be applied to $:/tags/EditToolbar $:/tags/EditorToolbar tags etc..
A step further;
The native solution is to add to the iteration of the view template tags the following;
:except[subfilter{$:/tags/ViewTemplate!!disregard-filter}]
Of note $:/tags/ViewTemplate is a shadow tiddler in empty.html
Once can use a filter here so something like [all[current]suffix[/classic]] would disregard tiddlers with that suffix.
We could say all “smart tags” include the possibility of leveraging the disregard-filter on the tag tiddler, we then need to apply it to the core UI components, although it would be a “code pattern” we can all use on our own tags. As a result if implemented would benefit from being added to the documentation.
I just returned to this as I was making a tiddler that displayed buttons on import tiddlers, listed import records when displayed in the story and sidebar. As a result it has the system tags for the sidebar and subtitle. These are needed but they are quite distracting when viewing the tiddler in the story.
All I wanted to do was to stop the tags displaying in the view template.
Modify the list widget in $:/core/ui/ViewTemplate to add the trailing NOT subfilter
<$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!is[draft]] +[!subfilter{!!$:/tags/ViewTemplate}]" variable="listItem">
<$transclude tiddler=<<listItem>>/>
</$list>
So I went to my tiddler and added the field $:/tags/ViewTemplate with the value [[$:/core/ui/ViewTemplate/tags]] and now just on this tiddler the tags view template will not display.
Using a field with the name of the tag “one wants to specify a delisting of” a/multiple items makes sense to me and makes it somewhat explicit.
This is a simple modification of the iteration of the $:/tags/ViewTemplate iteration process, similarly could be applied to all system tags applied to the currentTiddler allowing a specific tiddler to delist any or all items for the current tiddler only. It would make no difference unless a fieldname = the tag name is created.
We can introduce a new new story cascade item to introduce this alternate viewTemplate and this activate with a config entry.
I did not follow this thread in detail. Only saw the last post and thought I had to respond.
No. If you want to list tags in a tiddler, then tag them. All the mechanisms are optimised to use tiddlers.
IMO side loading stuff in that form will only cause maintenance problems, since users forget what they have done and then request for help, because it does not work as expected.
I personally do not see de-listing system tags as a feature, just because it needs to be explained. But if an “unlist-tags” field is used, at least there is a filter [all[tiddlers]has[unlist-tags]] that can show where it happened. … That’s an implementation detail.
IMO It still causes problems in the long run … but that’s my personal opinion.
There is a reason why we did remove the hideSystem tag in TW5. It caused more problems in TWclassic than good.
Just my thoughts.
Thanks @pmario for you thoughts,
Could you please expand on this a little more, I am not following
In my proposal one need only search for the tag name, and when it appears as a filter or as a fieldname you have found all its working. Or edit the tiddler on which you observe this behaviour.
I don’t recall this phase, if I recall we needed to revert to span and div somehow in Classic view templates. We have gone well beyond this now.
With the current implementation of view templates and the standard tag $:/tags/ViewTemplate as one example it “rules in” standard content. The only way to build exceptions such as don’t show the tags, or perhaps some other view template component , we have to include the conditional within the view template item. That is fine and the way we have been doing it for a long time. So I may have a footer or TOC tiddler and I give it the $:/tags/ViewTemplate tag and it is rendered, all fine because within it is a conditional display.
The problem comes if you want to “suppress an existing core component” as delivered by the $:/tags/ViewTemplate my example would be to hide the tags display, or the body when leveraging an alternative view.
Now I do know how the cascades work, if you follow that thread and look at using an alternate default view cascade or story tiddler cascade you quickly find you need to clone and edit or create quite a number of tiddlers. It gets complex quickly when all you want to do is suppress an existing view template element one a specific tiddler.
This is my proposal, and one I think could be valuable to permit exception handling, it is immediately visible on editing a tiddler that this applies to. It sits idle and invisible unless used.
Of course I am open to an alternate naming standard, rather than a field of the same name as the tag, but I think this somewhat self documenting. for example we could use delist-$:/tags/ViewTemplate or except-$:/tags/ViewTemplate containing the list of exceptions.
These are possible use cases;
$:/tags/ViewTemplate
$:/tags/ControlPanel/Info
$:/tags/EditTemplate
$:/tags/EditorToolbar
$:/tags/SideBar research this and more etc…
$:/tags/ViewTemplate/Subtitle
$:/tags/ViewToolbar
In closing although I think it would fill what I perceive as a gap in the core I am happy to use this as needed but I am forced to modify the core tiddlers, or build numerous cascades, in the spirit of hacking I would prefer it a documented feature.
As I wrote. System tiddlers are there for a reason. Hiding them, just because they are “ugly” is no solution for me.
But making them prettier could be an option. I could live with it, if system tags get a special icon and only that icon is shown. Or icon in combination with a tag-caption or caption field.
Not sure yet.
Just some thoughts
Mario, note hiding the tags view template on an individual tiddler is one example, or we may hide it and when hidden show an alternate, or hide on a specific tiddler(s) something i introduced to the view template.
I like your idea but for a separate need
I note this mechanism could reverse this solution from including all elements to excluding those not needed A difference when rendering a tiddler on its own as against rendering as part of a tab structure - #6 by Brian_Radspinner
