-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag-pill import (drag and drop) should include the tiddler at tag's home node, if it exists #8181
Comments
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:
|
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. |
Agree. I doubt this would have any serious backwards compatability issues. |
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.
(or whatever, probably with a pointer to the right section of the control panel too) |
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 $:/core/ui/ImportListing -- Does use the |
@springerspandrel The preview can be seen at: https://tiddlywiki5-git-fork-pmario-fix-8181-1abf17-jermolenes-projects.vercel.app/ |
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.).
The text was updated successfully, but these errors were encountered: