Suggested new behavior for tag dropdown list

[twMat]

tw.com create a new tiddler begin typing a new tag with string "$:/tags" in dropdown tag list, a few suggestions are seen.. but I was expecting to see all SystemTags. I'm guessing shadow tags are not seen.

• I suggest that an exception to show all shadowtags/tiddlers beginning with $:/tags
• what actually is supposed to show in the dropdown? Typing in "jer" in tag field seems the result in a more general search, i.e including searching tiddler content
• ...or maybe not: typing in "jer" I was expecting to see tag JeremyRuston but it only shows tag TiddlyWiki. This tiddler references JeremyRuston. However, JeremyRuston is also referenced in e.g tiddler Jermolene but Jermolene does not appear in the dropdown.

Unless I misunderstand something, I would say this ought to be dealt with as soon as possible. Here is my suggestions for how it should behave:

I presume one key use for tags is as a way to categorize tiddlers. As such one typically does not want more categories than necessary. For this reason, the system should help the user to avoid introducing unnecessary new tags. (Example: If intending to create a new tag "Jeremy" it is of value to learn about existing tags "jeremy", "JeremyRuston"... )

For these reasons, my first proposal is that the dropdown should show the following, and in this order:

1. tags with names starting with the typed string
2. tiddlertitles, that are not also tags, with names starting with the typed string
3. tags with names containing, but not starting, with the string
4. tiddlertitles, that are not also tags, containing, but not starting with, the string
5. tiddlertitles for tiddlers merely referencing the string in text, fields etc. (If these even should be suggested at all... but ok, they do have some relationship with the tag-to-be).

It may seem irrational to put in "(2) tiddler titles that are not tags" so early in a tag suggestions list - but in practice, they are a) very likely to be appropriate if they do start with the typed string and b) it is, again, of value to tag with something that already exists (regardless if a pure tag or a tiddlertitle). Number (3) is IMO a less likely 'search' than (2)

The above is my primary suggestion for behaviors. The following is something I would also like to see but is perhaps not as urgent:

Because tab pills have a rather small font size, I would prefer a clearer way to differentiate between tags that are tiddler titles and pure tags (which name are in italics in the tag pill). Again, the aim is to keep the number of tags small (and maybe there are other reasons?). For example;

• if a tiddlertitle and pure tag are 'similar', it makes sense to choose the title (because this connects the current tiddler with an actual other tiddler) and maybe you can even delete the pure tag.
• ...or vice versa; you may wish to use tags purely for categories and not as tiddlers. Take the ToC macro as used on tw.com for example: In closed state, you cannot tell if a ToC entry contains text or if it merely serves as a categorizer. On tw.com under tab Contents, compare e.g HelloThere with Customise Tiddlywiki. A visitor checking out Customize TiddlyWiki may wrongly conclude that the top level is merely a category name. ToC is autogenerated from tags so there is benefit in being helped with consistently choosing

So can we have some further way to (automatically) differentiate between pure tags and tiddlertitle-tags?

Thank you!

[tobibeer]

Perhaps, a more simple answer to your request is...

Let all...

• tags that start with string "$:/foo" show first ...and then...
• tiddlers that start with this string show first (so as to turn them into tags)
• then tags that match the string ...and eventually...
• tiddlers that match the string in their titles

[twMat]

• tags that start with string "$:/foo" show first ...and then...
• tiddlers that start with this string show first (so as to turn them into tags)
• then tags that match the string ...and eventually...
• tiddlers that match the string in their titles

Regarding the first, I think/hope you mean any tag "foo" rather than tags specifically starting with "$:/", right?

And you omitted my no.5, i.e:

1. tiddlertitles for tiddlers merely referencing the string in text, fields etc. (If these even should be suggested at all... but ok, they do have some relationship with the tag-to-be).

I included this because the current (faulty?) behavior seems to include them. E.g typing "jer" gives tiddlertitle "TiddlyWiki" which is not tagged so but does mention it in text. And maybe in fields. ...Not enough to suggest such tiddlers? I have no good answer.

Oh, and also the very first thing I wrote, i.e to

• make an exception for these tagging suggetions and show all shadowtags/tiddlers beginning with "$:/tags/"

[Jermolene]

I included this because the current (faulty?) behavior seems to include them

The relevant part of the template $:/core/ui/EditTemplate/tags is:

<$list filter="[!is[shadow]tags[]search{$:/temp/NewTagName}sort[title]]">

The "search" operator searches the title, tags and text of each tiddler.

[tobibeer]

What would you tink of a way of chaining filters where...

1. given selectors yield a given set of tiddlers
2. the selector-sets are consecutively chained
   • leaving only members in subsequent sets when not present in previous sets
3. thus yielding one big list of multiple, independently sorted, yet concatenated lists

...sorted first by occurence in a given sub-filter expression and only secondly in whatever sort directive was specifified.

In a way, the result would be a unique set of a concatenation of an array of arrays...

[
["foo", "bar", "baz"],
["baz", "mumble", "frotz"],
["baz", "gronk", "frotz"]
]

...yielding a result-set of :

["bar", "baz", "foo", "frotz", "mumble", "gronk"]

...when sorted by title, each set independently!

However, something tells me that a named grouping by set is preferable over a flat list that seems funnily sorted.

[tobibeer]

Is this fixed with #1353?

[tobibeer]

@twMat ...can you test /prerelease and see if this meets your needs?

As for duplication of entries, I have already made another pull request #1379, more specifically...

Line 26 and Line 30 at EditTemplate/tags.tid

[twMat]

Overall good but IMO we should also make an exception to have string "$:/tags/" result list all such tags. E.g on tw.com, this string only lists some 6 tags in the dropdown but there are some 13-14 actual tiddlers if you filter <$list filter="[all[shadows]prefix[$:/tags/]sort[title]]" template="$:/core/ui/ListItemTemplate"/> ...but I also think pure tags should be included, i.e all those listed in tiddler SystemTags

If someone is advanced enough to add tags of type "$:/tags/..." then he deserves to be presented all options. These tags are defined with the purpose of serving as tags so it makes sense to see them. It is also particularly easy to misspell these longer tag names.

As for duplication of entries

1379 does not seem to deal with duplications at all (but font color in pill text) and I'm not so good at interpreting the filters you refer to... but I'm guessing, and hope, that dealing with "duplication of entries" includes the following:

• in a dropdown omit displaying the lowermost duplicate. Specifically "lowermost" because that tags importance is as high as its topmost occurence in the list.
• omit displaying suggestions already used as tags in the current tiddler

[tobibeer]

at the moment, system tags get listed once they are used

personally, I would not list all of them, most of all because they tend to make the top of the list all the time and thus pop up a little too often, a little too dominantly ...perhaps they should be made to follow user tags

1379 does not seem to deal with duplications at all (but font color in pill text)

while that is true, it this restructures a lot of the code concerning the edit-template for tags ...and thus also handles duplication now, hiding those in the lower section and current tags, as you can see from the filters in those lines I referenced above

[twMat]

...pop up a little too often, a little too dominantly ...perhaps they should be made to follow user tags

You're right. But the idea to have them follow after is good. Is it possible to detect if such a tag has been used by the user somewhere? In that case, this tag should come at top IMO..

Hm, in further testing I realize that tiddlers starting with the string don't at all show first. IMO they should because I'd say the most likely is that the user is typing the first leters of the title he wants. The current /prerelease seems to not differentiate between the string at beginning of title or inside.

I also notice a change in how the dropdown pops up. In current release, it pops up on focus. In prerelease it only shows on typing and actually with about a delay ~2 sec.

---

Some other concerns that just might be easy to implement at the same time, if not then I'll post them as separate issues:

• It should be possible to make selection by starting to type followed by using arrow down key to select and Enter for immediate Add (plus focus shift to next, or possibly to text field. Currently there is no focus, thus forcing mouse interaction.).
• It is worth consideration that tagging was much faster in TWc. The current behaviour deals with constructing one tiddler at a time whereas TWc's "open" edit field for tags kind of made you write tags like writing a sentence. A downside was that you didn't get any suggestions or indication if you misspelled something. I think a combo would be ideal; you type in one field and there is a whatever-it's-called that interprets strings and pattern matches it so suggestions do come up for fast selection, but if you don't select anythihg then whatever is separated by space or encapsulated in [[]] is turned into a tagpill on the one final Add click. Selecting an tag from the proposal lists could give, not a tagpill but a tag on [[this form]] so to teach users that this is how to encapsulate space separated words and to give it more of an "edit look" than the pill which is a bit flashy for edti IMO. But then, maybe this would prevent eventual features for tagpills in edit view (such as clicking them to do something, like hiding or editing it's color etc).

• 1220 is relevant here too, i.e to get an alert on tiddler Done that you have unsaved fields (here a tag edited without clicking Add)

[tobibeer]

You're right. But the idea to have them follow after is good. Is it possible to detect if such a tag has been used by the user somewhere? In that case, this tag should come at top IMO..

Personally, I think any system-tiddler should never be up top, because it's an internal feature. I'd want to see content tags first, even though that generic sorting puts $ before a. I would rather like to see all non-ascii characters behind alpha-numeric ones, if only for the starting character.

Hm, in further testing I realize that tiddlers starting with the string don't at all show first. The current /prerelease seems to not differentiate between the string at beginning of title or inside.

That is, mostly, because there is search operator that does such sorting. I created a new ticket: #1399. This would come with the benefit of placing system tags behind those that start with the typed string.

I also notice a change in how the dropdown pops up. In current release, it pops up on focus. In prerelease it only shows on typing and actually with about a delay ~2 sec.

That is because the new popup lists all existing tiddlers at the bottom, which seems to slow things down considerably. Possibly, tiddlers should only be shown when a search term (longer than x) has been entered.

For that, there possibly needs to be a new type for the reveal widget that would check the length of a string and do something based on that. Made another ticket for that also: #1400.

Some other concerns that just might be easy to implement at the same time, if not then I'll post them as separate issues

Please, consider this option more often! It's not good at all if issues get bloated up like that. They should be small and actionable, not entire topics! When you write an issue, rather than "suggested new behavior for tag dropdown list" it would ideally be titled with the precise behavior you want. And if that is multiple things, it's multiple, independently, cross-referenced issues.

make selection by starting to type

there is an issue for that, go find it

It is worth consideration that tagging was much faster in TWc.

new issue! => #1401 Personally, I would like to be able to just globally toggle between interactive and simple text field

1220 is relevant here too

nope, it isn't it's a distinct issue

[twMat]

Personally, I think any system-tiddler should never be up top, because it's an internal feature.

Thing is, when you use a system title as a tag, it becomes "yours". It is no longer an anonymous name of a system tiddler, but it's not your fault it happened to still be titled like one such. I wish we could treat user used system tags differently from other system tags in the displays.

I'd want to see content tags first, even though that generic sorting puts $ before a. I would rather like to see all non-ascii characters behind alpha-numeric ones, if only for the starting character.

Created #1402

The slow loading of all titles in the popup

[...] Possibly, tiddlers should only be shown when a search term (longer than x) has been entered.

How about this: We use your distinction and physical separation between tags and non-tags! Load one at a time. The user gets to see the tags while the non-tags are still being rendered. It is likely that if there are very few tags, then it is a new TW and there are also few non-tag titles meaning it would be fast to load that list too.

...there's probably still the freezing though, when you can't type. Still better to look at a list while frozen than nothing.

Could typing interrupt the filtering? This is desirable because typing means you want another (filtered) list anyway.

I also notice that the delay occurs for each new tag that I want to add. Maybe the originally rendered list could be kept in memory so it won't have to be calculated again?

Or maybe there is a point in workflow that could be taken advantage of; it is reasonable to expect that tagging is common, so maybe the list could be rendered whenever you go into tiddler edit mode, at least for new tiddlers. I would guess people don't create tags as the first thing they do but instead title or text. Would it be possible to calculate tag list while he's busy typing title or must, as indicated in a simple test I just did, everything in TW freeze?

posting as separate issues

Please, consider this option more often! It's not good at all if issues get bloated up like that. They should be small and actionable, not entire topics! When you write an issue, rather than "suggested new behavior for tag dropdown list" it would ideally be titled with the precise behavior you want. And if that is multiple things, it's multiple, independently, cross-referenced issues.

I definitely understand your point and I think this is one reason why people are not comfortable using github. I wish all threads were initially discussions, unless otherwise specified, but that one could tag or select individual posts as "small and actionable" and have these filtered out separately. We miss out on potential stuff due to such infrastructure limitations. For instance, I probably belong more on the google boards but I think that some of the things having come from my participation in github over the past 2 (3?) months would not have come about if I limited myself to the boards. But... just maybe I should switch back actually.

[tobibeer]

I think it's ok to discuss here and I think that's what Jeremy uses the "discussion" tag for. So, I'd leave it up for him to decide on preferences about that. The thing about "discussions" is, though, (when) will they ever get closed? It's hard to tell. Nobody will read through 20 long posts to figure out if there are any actionable items left, I guess.

[twMat]

To not fall further into the very trap we're discussing I created #1403

[pmario]

@Jermolene ... imo should be labeled "discussion" and "improvement"