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

Developers
, ,
#43

@Yaisog, I don’t think this is quite enough. We want to display (in the tag pill) only the tiddlers that “claim” the tag, and none that don’t.

The unlist field (or disregard or de-list or whatever) could (over time) include some values that do not correspond to tiddlers that claim the tag. Those should not be in the tagpill.

I’m looking for the equivalent of [enlist{!!disregard-list}] :filter[<currentTiddler>tag<thisTag>] (which behaves fine in my wiki)…

But we would need a different formulation, if your elegant javascript version doesn’t “see” the tiddler-side tag … [<thisTag>listed[tags]] feels like it should work (and does work by itself, but not as a :filter run… )

#44

Right, I didn’t think of that.

<$list filter="[enlist{!!unlist}tag:raw<currentTiddler>]">

This should work, since tag:raw[] ignores the unlist list. The same filter expression needs to go into the <% if statement. I’ll update my code above.
This is another way to do it:

<$list filter="[tag:raw<currentTiddler>] -[tag<currentTiddler>]">
1 Like
#45

Ah, right. Sorry I was losing track of that detail!

#46

I agree, I love naming competitions, word smithing, and like in flags a good choice at the beginning lasts forever.

My thoughts are although tags generate lists that is a simplification. in reality it remains a tag list, from which you are hiding a tag from the list.

perhaps it could be hide-tag(s) or a variation like exclude-tags. after all the titles are excluded from those identified as tags.

your choice here :nerd_face:

1 Like
#47

What about “masking”? In graphics software, “masking” is used to make some parts of the image immune to current tool.

Fred

#48

Interestingly I decided to use my flags solution as a Glossary, on my book writing site.

Normally there is a view template applied to any flag tiddler, however I want the Glossary to be in alphabetical order, rather than in a drag and drop list.

As a result I have an example where I would like to defeat the applkication of this excluding $:/PSaT/flags/viewTemplate from the items tagged $:/tags/ViewTemplate on this tiddler only.

  • An example of this disregard idea.
#49

I realised in this discussion an apploach I took through the reimagin tags, or the tag drop down was the ability to disable a flag on a particular tiddler, was a button to rename it, with a known prefix (dont relink) and a button to rename it back when needed.

  • It is not what the Topic asked but it is a related technique.
  • The advantage is you dont loose the information that is was tagged in the first place because it is now tagged disabled-$:/tags/ViewTemplate as an example.
#50

For the future me who will not remember which tags have an unlist entry and will perpetually wonder why some part of the UI cannot be made to show up, here’s a barebones overview of all tag tiddlers that have been modified in a wiki:

The following tags have exceptions defined via the `unlist` field:

<$list filter="[is[tag]has[unlist]]" >
	<$link>
		<strong><<currentTiddler>></strong>
	</$link>
	<ul>
	<$list filter="[enlist{!!unlist}]" variable="item">
		<li>
			<$link to=<<item>> />
			<% if [<item>!is[tiddler]!is[shadow]] %>
				- does not exist
			<% elseif [<item>!tag:raw<currentTiddler>] %>
				- not tagged with <<currentTiddler>>
			<% endif %>
		</li>
	</$list>
	</ul>
</$list>

This will yield something like this:
image

Also includes some reminders to clean up.

Alternatively, use <<tag>> instead of <$link> at the top level for a more “taggy” look.

1 Like
#51

FYI a more “taggy” look, the standard terminology is a “tag pill” :nerd_face:

Keep in mind many tag pills don’t have a tag tiddler, except for those that are in a tag tree like the contents/a TOC.

@Yaisog could you summarise and explain your approach in a single reply please. Is it only possible in a custom list or items tagged or can it work in a tag like $:/tags/ViewTemplate

#52

on a related subject the may be a common desire to toggle a tag on on a tiddler, for example to add or remove a view template tag. it seems to me that this is such a common requirement that perhaps we could provide a user interface element to make it easy for users of a wiki. similarly for the solution above.

Such a user interface element should not need to refer to tagging, or hiding a tag but the function it performs. eg display feature.

I think a checkbox may be the suitable UI element and whilst it may be tempting to build it to toggle tags it could be generalised to toggle a value on any list field, tags being one of them, flags being another.

My idea here is perhaps to introduce a macro, ultimately into the core to help new and advanced users. Which begs the question what other UI gaps could we address?

  • perhaps a search to add a title to a field or remove items from a list.
#53

I haven’t kept up with all replies here, but I have made the following additional feature available at quick-demo:

Populate the tag-override-filter field, at a tag tiddler, so that the tag-pill can display some list other than the default [<currentTiddler>tagging[]] (Generally this will be a list starting with or based on the basic list of tag-childer, but it may add other nodes, or possibly leaving some tagged tiddlers out, as needed.)

Unlike the basic idea through most of this thread, this solution is specifically intended to include virtual nodes that would otherwise be impossible to list within a tag pill.

For example, a tagpill for fields-for-bibtex could include ALL fieldnames that start with bibtex- including fieldnames for which there is no tiddler.

Obviously, this is specifically useful for wikis where there is some kind of virtual-node apparatus for doing important things with fieldname nodes (such as showing an overview of field:value pairs for tiddlers that have the field in question).

There are various ways in which tag functionality is deeply designed around expecting only actual tiddlers to be listed in the tagpill dropdown. So this solution is a work in progress, intended (as is much of this work!) as a proof-of-concept.

EDIT TO ADD: This additional development overlaps (again!) with the work Tones has been doing on “flags”… But here I’m again sticking more closely to the idea of working with the tag tiddler (and much of its role in the core) so that it can be adjusted or tinkered-with to handle different demands.

2 Likes
#54

@Springer I have just being looking at your Demo wiki, If I may clarify you propose; including a disregard-list on the tag tiddler, then where that tag tiddler is iterated, include at the end of the filter the following;

-[[$:/tags/ViewTemplate]has[disregard-list]get[disregard-list]enlist-input[]]

Thus this would mean either we change the core or modify the viewTemplate mechanisum, although we then only modify the tag tiddler to include a disregard-list?

If we wanted to generalise this for all system tags, I have some other methods to implement the change throughout the wiki if you wanted to propose this, whilst essentially using the method you demonstrated.

  • Lets discuss further if you would like to persue this.

Is there an opportunity to programaticaly disregard an item in a tag list such as via a filter in this implementation?

  • One trick could be to hide an item using disregard, then include it back via a conditional inside a new item.

Eg a core tiddler with $:/tags/viewTemplate - eg the display of tags uses $:/core/ui/ViewTemplate/tags, let us say we wanted to stop the editing of tags on system tiddlers, we would add “$:/core/ui/ViewTemplate/tags” to the disregard list, and the tag viewer would not appear one ANY tiddler.

  • however before hand we could have cloned $:/core/ui/ViewTemplate/tags and wrapped the content with a condition !is[system] we could also add a config tiddler to switch this feature on or off.

As a result we stop displaying tags for all tiddlers, then redisplay the tags on tiddlers that are not system tiddlers.

Have I got the idea?

#55

This is very clever! It feels like a natural extension of the virtual tiddler system, and I should probably adopt it ASAP.

My first thought was that if @Springer replaced

-[[$:/tags/ViewTemplate]has[disregard-list]get[disregard-list]enlist-input[]]

with

-[subfilter{$:/tags/ViewTemplate!!disregard-list}]

you could add a filter run like [<currentTiddler>is[system]then[$:/core/ui/ViewTemplate/tags]] to $:/tags/ViewTemplate's disregard-list, and then you wouldn’t need to clone anything. In my quick test just now, this doesn’t seem to interfere with the add/remove-from-disregard-list toggles — though it does make a title’s presence in the list less obvious.

1 Like
#56

I would make this more sophisticated so it reads something like;

-[subfilter<disregard>]

or if nessasary

-[subfilter<disregard "tagname">]

Similarly

...[disregard.filter[tagname]]

where disregard is a global function that can be deployed to all tags and we could even redirect disregard to others tagnames, or to disregard other than just tags, eg flags.

  • In this case the idea of a disregard feature is implemented and tag-children is but one example.

or

...[disregard[list]]

PS. This would be easy for me as I have done it many times. ie we could submit a dozen mods to the core that add something as simple as the operator disregard where list is as needed.

#57

Mm, I understand the argument, but personally, I wouldn’t. I think using a single field on the relevant tag tiddler is both elegantly simple and easily understood: it doesn’t require you to follow a daisy chain of definitions from tiddler to tiddler. (And I say this as someone who makes heavy use of global functions and variables in my own wikis — it makes it much harder to reconstruct how something works, and more time-consuming to modify it.) If the list field appears directly on a tag tiddler, I think it makes sense for the disregard-list to appear there, too.

Edit: Unless you mean that the subfilter would still be ultimately stored in !!disregard-list, but the filter [subfilter{$:/tags/ViewTemplate!!disregard-list}] changed to something easier to parameterize like [disregard.filter[$:/tags/ViewTemplate]]? In that case… I’m cautiously in agreement, but I’m still wary of complications that make it different for users to understand what’s going on. Most people won’t be as comfortable with Advanced Search as you or I. :wink:

ETA 2: I suppose disregard-list might also be more aptly called disregard-filter if it can accept filters rather than simply title lists… :thinking:

1 Like
#58

It is possible to have both your emphasis and my own, if designed well.

  • I have not said anything different to this, although it can apply in more places.

But keep in mind if we do one day promote it to the core it will be acompanied by documentation both for ease of use/reuse and we can document the mechanisium (not always done sadley).

Me too, infact that is why I proposed this. Sure I have not illustrated this yet.

If we pause to consider the bigger picture, the act of adding titles to the disregard-list, is itself a few steps, and a number of related discussions of late are all about populating list fields, field handling and more. So I see more opportunities to support users/designers with helpful but not essential improvements. hmmm that sent me on another idea;

In a way what we need to do is;

  • Establish a defacto standard - The use of the disregard-list
  • Provide a helper to apply the disregard-list
    • If designed well this may allow (though not insist) more sophisticated applications
  • Apply the defacto standard into the appropriate core tags, perhaps thus becoming a Dejure standard.
  • let people to use the disregard-list or filter mechanisium as they wish

afterthought include a regard-list ?

#59

The thing about a filter is that a list is the limit-case of a simple filter. So you could use tag-override-filter to type in a list of actual titles, and that would be a filter. Or have the filter field be a hybrid like [<currentTiddler>tagging[]] ThisExtraTiddler ThisVirtualNode

#60

I thought this as well, but a recent attempt to do this did not work for me :thinking:

Could you present a simple example?

#61

Too Long and I still read it all again.

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…

  • However I am now working on a native tiddlywiki approach with the same functionality.
#62

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.