Tag-pill import (drag and drop) should include the tiddler at tag's home node, if it exists

[springerspandrel]

Dragging a tag pill from one wiki to another currently serves to copy over all the tiddlers under that tag. However, it does not copy over the tag tiddler itself — the “home base” node for the tag — even when there is a tiddler there at that logically important location.

Problem: This default behavior is a problem given that the tiddler at this location (home / root / brain / key / core / hub for tag) has increasingly become a natural and appropriate place to organize all sorts of germane info and resources. For example, this tiddler is the best place to include an explanation for a community-shared solution informally bundled under a tag, an teaching overview or note-to-self of why a tag matters, or substantial info about a type or genre or category within the wiki, perhaps with a custom overview list or table tailored to the fields associated with tiddlers under this tag. Further, order information for a tag is stored in this tiddler's list field — and leaving that list order behind when those details are vital (as for example, in a cascade-based solution) can cause confusion and headaches, especially for newcomers. Some people also care about retaining assigned tag color across multiple wikis, and are surprised when dragging a tag pill doesn't retain the color (since it's stored in the tiddler for the tag, which is by default left behind).

Solution: I'd like to see the tag-pill's default drag-and-drop behavior extended, so that the tag's home-base tiddler (if it exists) is included in the tag-pill's payload. I'd hope to see the tag's main tiddler displayed above all its "children" if that's easy, so the list looks a bit like it does on the tag-pill's default drop-down. (If the import process can't easily pull it to top of list, that's minor.) As with any import, users will have an opportunity to exclude this tiddler (or any other) at the arriving payload-confirmation dialog, with visual flag for conflicts.

Alternatives?: Workarounds include (a) custom filter-pill-style solutions and (b) self-referential tagging. The first (a) is a lot of work to accomplish something that's straightforward (and should be available to beginning users); the second (b) is bound to create mischief for projects that want simple tag-hierarchy structures, and to undermine other powerful uses of tags (such as to serve as criteria for view templates, cascades, etc.).

[CrossEye]

Note that there is more discussion on this issue on talk.tiddlywiki, including a workaround from @pmario that might offer a useful suggestion for a fix:

• open: $:/core/ui/TagTemplate
• change dragFilter="[all[current]tagging[]]"
• to dragFilter="[all[current]tagging[]] [all[current]] :filter[is[tiddler]]"
  • Be aware: this filter does not copy shadow tiddlers, if they are not modified

[Jermolene]

I agree with the idea of making dragging a tag pill include the tag tiddler itself.

As usual, there is the question of backwards compatibility; I would favour changing the default behaviour which undoubtedly not be backwards compatible. However, it isn't obvious whether changing the behaviour would cause significant practical problems for users. Particularly if we were able to implement your suggestion of having the tag tiddler at the top of the import list; it would be very easy for users to deselect the tag tiddler if they don't want it.

The obvious alternative would be to pull the drag filter into a config tiddler and then expose it as a setting in control panel, but that can be a bit of a cop out, pushing more complexity onto the user.

Or perhaps for the moment we could just document that config tiddler as a hidden setting, and not change the default.

[TiddlyTweeter]

there is the question of backwards compatibility; I would favour changing the default behaviour which undoubtedly not be backwards compatible. However, it isn't obvious whether changing the behaviour would cause significant practical problems for users. Particularly if we were able to implement your suggestion of having the tag tiddler at the top of the import list; it would be very easy for users to deselect the tag tiddler if they don't want it.

Agree. I doubt this would have any serious backwards compatability issues.

[CrossEye]

The obvious alternative would be to pull the drag filter into a config tiddler and then expose it as a setting in control panel, but that can be a bit of a cop out, pushing more complexity onto the user.

Well, if we did that as an easy way to restore backward compatibility, I wouldn't think of it as a cop-out at all.

"In version 5.3.4 the behavior on dragging a tag pill to another wiki has changed slightly. As well as dragging all the items with that tag, it also drags the tag tiddler itself, if that tiddler exists. This one will appear first in the import list in case you want to deselect it. If you want to restore the behavior from earlier versions, simply update the text of $:/config/DraggedTagFilter to read [tag<currentTiddler>]."

(or whatever, probably with a pointer to the right section of the control panel too)

[pmario]

[. . .] Particularly if we were able to implement your suggestion of having the tag tiddler at the top of the import list; it would be very easy for users to deselect the tag tiddler if they don't want it.

I think that's not simple. If a tag-set is exported, the file JSON or CSV does not include any info, that the set contains a <<tag abc>> configuration. It could be anything.

$:/core/ui/ImportListing -- Does use the sort[title] operator, which most of the time makes sense.

[pmario]

@springerspandrel The preview can be seen at: https://tiddlywiki5-git-fork-pmario-fix-8181-1abf17-jermolenes-projects.vercel.app/