Dear all,
I’ve gotten used to this behavior, but I think it’s worth checking in on as our practices evolve.
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 that home node exists. I think of this as the “headless tag-drag” (with English-slang pun intended). I imagine the behavior is left over from when tags didn’t do much besides dress up as colorful pills below the subtitle of tiddlers so tagged. If they had content themselves, it was usually limited to housing a draggable list-order in the list field, which usually had little non-cosmetic function. Is that right?
But whenever there really is a tiddler there, shouldn’t the presumption now be that its content is integrally related, and hence of potential interest (by default) to someone dragging the tag pill?
Is there any advantage? Maybe there’s some convenience associated with the current “headless” drag behavior. For example, I could drag over the tag pill $:/tags/Stylesheet from someone else’s wiki, and get all the remote tiddlers so tagged, without overwriting the home tiddler I’ve set up for $:/tags/Stylesheet (with its list field, its tag color, whatever else I’ve set up already).
Disadvantage #1: Many of us have been developing systemic intensive uses for the “home base” node for all or most tags in a wiki. I’d like to be able to say: “Drag this tag pill over to your wiki, and you’ll have all the things.” But instead I need to say, “Drag this tag pill over to your wiki, and ALSO come back here and drag over this tag-home tiddler title itself, so that you have all the things.”
Disadvantage #2: Sometimes the list order details housed at the tag’s home tiddler are really crucial to making something work, in ways that a novice user may not realize. I’m thinking especially of how cascades work, and how easily they’re broken if someone ends up with the vertebrae, but not the spine that helps hold them in a well-ordered string.
Awkward workaround: Perhaps someone will suggest that I self-tag a tiddler whenever the content at the tag’s home-base tiddler is a helpful part of the package, so that it’s not left behind when the tag-pill is dragged. This solution makes me cringe on lots of levels. For one thing, a certain view template often make sense for every tiddler tagged a certain way, but not for the home tiddler of that tag. Also, self-tagging just seems ripe for setting up unwitting problems down the road.)
We already have an import dialog that allows something to be de-selected…
It seems more friendly to have the tag home tiddler included by default — and de-selectable in the import dialogue — than to simply leave it behind, by default.
Apart from the marginal cases where someone’s habits might need to be tweaked (to scan for the incoming tag-home tiddler if it exists, and de-select if necessary, which probably would matter only when it’s also a conflicting tiddler — and hence the kind of thing we scan for at import time anyway)… I don’t imagine there’d be any backward-compatibility reasons to stick with “headless tag-drags”… What do you all think?
Is it worth developing the “head-inclusive tag drag” (maybe not by that name!) as a plug-in, and playing with it for a while, see how it feels?
