How to snatch tags from another tiddler?

[EricShulman]

@vuk

The edit field does not behave like the “main” search of the TiddlyWiki - the appearing menu stays empty as I type.

Mobile browsers don’t render $select lists in the same way as other platforms. They ALWAYS render them as single-line drop-down lists, so no value is displayed until the input exactly matches a single entry in the list. The reason this doesn’t occur for the “main search” is that that interface doesn’t use a $select list at all. Rather, it creates it’s own popup “div” in which it renders clickable tiddler links that navigate to tiddlers, which is completely different from selecting a value to populate an input field.

-e

[vuk]

@EricShulman

This seems to be a side-effect of using a tag that begins with “+”.

I asked about this very recently and was told it should be safe

What are common conventions for partitioning tags into namespaces?

TiddlyWiki docs state: A tag is in fact just a tiddler (or a potential tiddler), and it can have tags of its own. TiddlyWiki makes use of tags for example for organizing a set of tiddlers into a hierarchy, which is used to automatically build a Table of Contents for example. So, for example “Working with TiddlyWiki” is a legit tag. However, I’m also used to another definition of tags - when they are laconic, single words used to capture the essence of bigger chunks of information. But using…

[EricShulman]

I’ve managed to fix the “leading +” issue so it doesn’t add the “poltergeist” tag!

Instead of using

<$action-listops $tags="[<tid>get[tags]enlist-input[]]"/>

my code now uses

<$action-listops $field=tags $filter="[enlist{!!tags}] [<tid>get[tags]enlist-input[]]"/>

As previously noted, the problem was the $action-listops widget handling for $tags="[...]", which treats the parameter value as a subfilter, and thus was interpreting the leading “+” in a tag value as a filter run prefix, which produced the unexpected results.

In contrast, by using $field=tags $filter="[...]", the $action-listops widget does NOT treat the $filter parameter value as a subfilter. Thus, we can explicitly combine the existing tags with the “imported” tags by using [enlist{!!tags}] [<tid>get[tags]enlist-input[]], and a leading “+” in a tag value is no longer interpreted as a filter run prefix.

TA DA!

Of course, we still have the problem of mobile platforms completely screwing up the multi-line list box rendering by forcing it to be a single-line droplist

Get the updated TiddlyTools edit template here: TiddlyTools/Templates/CopyTags

-e

[vuk]

Thank you very much.

Quite a challenge to browse your site on mobile. For some reason I could not select the code by tapping on it, to copypaste it into a tiddler of my test wiki. But I managed to get it by simply exporting the tiddler from there then importing it.

It’s also very laggy, I don’t know why. Maybe my phone does not have muscle to process it. But I can navigate other wikis fine. It’s a pity, because there’s a lot of useful content there.

[TW_Tones]

@vuk

I asked about this very recently and was told it should be safe

It should, and is now with Erics solution. But there are always degrees of safe. Personally just as with tiddler titles, tags with a “symbol” are in a way a compound tiddler title, and this is frought as well, I recomend against compount titles. There is always another way to do it, and each of those ways may on a rare occasions clash with another solution obtained elsewhere.