“Headless tag-drags”: default D&D behavior for tag pill leaves home tiddler behind. Should it?

#21

It can hurt, especially, if its a system tag, and given the current behaviour is the basis on which others have designed solutions . Dragging the tag tiddler to another wiki will overwrite the current tag tiddlers and possibly the order held in the list field, of the tags tiddlers.

We call them “missing tag tiddlers”. Whilst your terminology has it merits, there is already an established terminology, this would clash with.

  • Also the example sometimes used the root of the contents is the TableOfContents tag, or the root of a heiraqchy.

I did propose what I did from a deep and informed perspective, and it will add a feature;

Similarly if it is important people can take steps to include it, such as a package with the filter [<currentTag>] [tag<currentTag>] but if you make it automatic they have to uncheck it at import (which is a horror to document).

  • As I said I have soutions coming that will assist and do think this breaks backward compatibility.
1 Like
#22

Right.

The recursive nature of The Bundler makes it an Epic Achievement.
And that makes it very useful.

Regarding this thread we have similar issues arising for Taggery Transport?

(These comments are from the Peanut Gallery.)

#23

Here is a workaround for the time being.

  • 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

So it looks like the following screenshot.

Important: I did some basic tests, but I do not know if there are any unwanted side effects. So you’ll need to do more testing.

image
image1502×883 55.4 KB

The template is used 5 times in the core UI.

image
image1502×509 18.9 KB

And that’s where it is supposed to work in the new way.

have fun!
mario

2 Likes
#24

Wow, this is perfect! I had no idea…

#25

I guess that makes sense. The largest project of which I’m a maintainer does not have a dedicated forum, so Issues often serve that role too. With a separate forum (as well as the GitHub discussions), that is not really necessary.

#26

We do have a lot of open issues that are basically discussions, because we did not have GitHub discussions in early days. If “discussions” are issues the advantage is, that they will not be forgotten.

Jeremy does not close them as long as they are valid. Closing requests with a “wont-fix” is very, very rare.

In my opinion discussions are putting a lot of noise to GH issues. – But that’s my personal opinion.

At the beginning, Jeremy did “label” the issues, but that stopped at 2015. So you have to read the “story”, “external links” and “internal links” to know, if it is still valid and what it is about.

At the end of 2023 I did put the effort into it and read all of them. About 1000+ issues and we where able to close about 150 issues or something like this. So for a short time we where back below 1000

GH discussions is not really up for the task to serve a “non developer” community. It is targetted for developers and the UX is not really convenient. The advantage would be, that issues could be converted to GH discussions and and vice versa but that was rejected.

I think Discourse is much better as a community forum, where we can discuss topics in “free form”.

Devs, especially Jeremy, are “time constrained” so the clearer an issue is, the easier it is to work with it.

A GH issue needs to contain enough information that it is “actionable” on it’s own. So it should not be needed to “jump links” to start working on an issue or new feature.

2 Likes
#27

I am not a fan of a “payload-field”, because I would need to modify the “tag tiddler” itself. If I do have several 100++ tags, I would need to touch them all. I would prefer a global solution.

That’s exactly what d&d import should do. It should overwrite existing tiddlers with new tiddlers, that are imported. If there is an existing tiddler, the user gets a warning and has to resolve the problem.

It’s the users decision, what they want to do

2 Likes
#28

I haven’t read all of the discussion subsequent to this comment, but I don’t think I agree with all of @pmario’s remarks on assessing the quality of pull requests.

While brief, simple PRs are welcome, for many complex problems that is not possible, and a more detailed explanation is required.

Things that make it more difficult for to process a PR include not being self-contained. My least favourite PR description is a solitary link to a discussion here on Talk. The GitHub history of the project is a vital and enduring resource, and so the story we’re telling shouldn’t depend on ephemeral external links

The reason that some PRs stall for a long time is usually when they raise difficult decisions about backwards compatibility, or constraining future compatibility.

We’ve tried to summarise the important points for a good pull request here in contributing.md.

2 Likes
#29

I was thinking that if this field is present, it would override the default.

If I want to copy all the Person tiddlers, their Avatar images, the template I use to show them, and the stylesheet that uses, I might do this:

title: Person
tags: TableOfContents
_payload-filter: Person [tag[Person]] [tag[Person]get[avatar]] $:/_/my/templates/person $:/_/my/styles/person +[unique[]sort[]] "
...

Then dragging tag Person to another wiki grabs all the important things I associate with my group of Persons.

I agree that we should think of the OP as a bug, and that we should update the default . But Tony’s suggestion would be a good mechanism to allow us to use these TagTiddlers in a more powerful manner. If there’s no field, we will have a sensible default.

1 Like
#30

Github thread started: Tag-pill import (drag and drop) should include the tiddler at tag's home node, if it exists · Issue #8181 · Jermolene/TiddlyWiki5 · GitHub

2 Likes
#31

That’s always been my standard.

Would you grant an exception for a PR which simply links to the GH issue that it solves, and then details only what’s required to explain the solution to the problem described elsewhere?

#32

I think it is still helpful to give a summary of the bug along with the link to the issue.

I get GitHub notifications via email, so the first time I see a PR is typically a notification on a mobile device, so it’s much more convenient not to have to click a link.

A frustrating thing about links in PRs is following them and then finding that it was unnecessary. Giving plenty of context for the link is immensely helpful.

#33

Yes, but also the tagging tiddler, carry the metadata used to organise data from one wiki to another?

In most cases a tag acts as metadata, putting a mark on all related tiddlers. The fact is you can use this metadata to mark a set of tiddlers, which if dragged this selects the tiddlers to drag.

As it stands this is good for the transfer of tiddlers from one wiki to another, and allows you “add these tiddlers to the same metadata tag, in the receiving wiki”. People are already making use of this behaviour.

If however you add by default inclusion of the “tag tiddler” this behaviour changes, and has the potential to lose information if that tag or metadata already exists in the destination. If this happens there is no specific info, just a warning that the tag will be over written during import, it is not highlighted in any special way, and what is the consequence will not be clear.

  • To try and stop this occurring will require instructions, at the appropriate time, and is hard to implement.

@Springer’s original suggestion makes sense on say a tag that represents a package of tiddlers, in the source wiki and unlikely to be in a destination tiddler but otherwise I would advise against doing this at all, apart from implementing a change, a new default.

  • It was also pointed out you can tag it with itself but there are some cases this would be problematic.
  • I suggest adding the ability to customise the behaviour, an example may be a simple field that indicated to include the tagging tiddler when dragged, but if we are adding a field it may as well be a filter instead and add more features.

I am happy to be persuaded otherwise, but I believe changing the default bevhaviour should not occur.

1 Like
#34

I do understand that any backward-incompatible change has to be approached with caution. But there’s a competing concern about not letting that caution prevent us from progressing at all.

In that spirit, I’m wondering if you can demonstrate any real-world wiki where this would be a significant problem. I know it’s easy enough to create scenarios where this would launch the missiles and steal one’s boy/girlfriend, but can you point to any actual wikis where this would cause harm?

#35

As with any import, overwriting a tiddler you already have can involve data loss. So if there’s already a tiddler serving as “home base” (or brain, or root, or key, or hub, or anchor) for that tag, then that tiddler (including its color field, list field, any contents of text field, etc.) would be overwritten… unless of course you don’t want to overwrite it, so you uncheck it at the import dialog.

All true. Yet this is exactly the kind of risk that we already have when the payload of any tag pill might overlap with tiddlers we already have in the receiving wiki… And that’s why we have a clear visual cue for overwrites, and tools to compare diffs…

I’m not sure what you mean by saying that a tag “or metadata” might be lost — as if there’s a second thing that can be lost?

Importing the tiddler (the one that anchors a tag) would not affect any of the data connected to other tiddlers in the receiving wiki; it wouldn’t change which existing tiddlers already have the tag, or anything else about them and their fields. Even if the incoming tiddler has a list field, that list field affects order, but doesn’t actually settle which tiddlers have the tag. Each other tiddlers’ connection to the tag is stored in that tiddler’s own JSON entry, and if those other tiddlers have a list-before or list-after field, those also remain unaffected…

It seems that once this option is enabled in the core, it could be easily disabled or reconfigured for anyone who is worried that even the option to exclude at import is insufficient — and who thus prefers, as a rule, to prevent any tag-parent from accompanying their tag-children in the same tag-pill when the tag-pill travels.

I have no particular attachment to having this behavior on by default; I’ll be tickled to have it available and easily activated.

Still, I think both you (@TW_Tones) and I have increasing been learning to leverage the organizational power of tags as important structural nodes in a wiki, and this change (along with making tag-pills display in italics if there’s no tiddler there, to mirror how tiddler links look when there’s no “there” there) would maximize the coherence of this trend.

#36
  • Dragging a system tag like $:/tags/macro global or viewtemplate.
  • Dragging a set of tiddlers tagged person, to another wiki also containing tiddlers with the tag person.
    • Any establish sorting will be lost.

If someone wants the tag to drag the tag tiddler with it, they can and I think they should rule in the behaviour.

  • This need has not being raised to my knowledge for a long time, so taking a rare mention and changing tiddlywiki as a result is unwise.
  • Needing to Rulling out the behaviour is unnessasarily complex.
  • I am not saying it should not happen, I am saying not by default.

If you are really keen, add a config item to “include tag tiddler with tag drag and drop”, I recommend not by default, but by choice.

#37

Personally, I would be most concerned about functional tags like $:/tags/Stylesheet and $:/tags/ViewTemplateBodyFilter. These are both tags I use extensively, so I just tested it by dragging some “default” versions into my main wiki.

  • Losing the ordering of my stylesheets didn’t introduce any obvious breaking changes, but I did notice some minor issues (even though I’m using a custom layout with its own stylesheets, largely independent of the Vanilla theme). I can certainly imagine this causing bigger issues for someone else, since sequence is such an integral element of CSS overrides.
  • Importing $:/tags/ViewTemplateBodyFilter put $:/config/ViewTemplateBodyFilters/default back above my custom filters, so all the tiddlers that had been using custom view templates defined through the cascade (the vast majority of them, in this wiki!) immediately reverted to the default view template. (Ironically–and frustratingly—this included the filter/view template I’d been using to display tag pills on system tag tiddlers, so it took several more clicks just to find the tag pill so I could reorder it.)

Of course, I’ve been using TW long enough that

  1. I do check “diff (fields)” when importing.
  2. I keep regular backups, so this would be an easy fix if I did happen to miss something.
  3. I’d probably realize what I’d done wrong sooner rather than later, and
  4. I could probably reconstruct my work without too much headache, even if—for some reason—I didn’t have a backup.

So my concern is less for myself than for newer users, who may not have these skills and best practices internalized, and who may not even recognize how or why overwriting a tag could cause problems. Newer users (in my personal experience) are also pretty likely to import anything that looks even mildly helpful from public wikis in the wild, and a lot of these—even the ones offering intentionally packaged solutions—haven’t been updated in years; they won’t come with any warnings that the D&D behavior has changed. So, IMO, the people most likely to be adversely affected by the change are also the ones least likely to have the tools/knowledge needed to easily fix their mistakes.

#38

I’m curious. Do either of you do that regularly? I don’t think I’ve ever dragged a system tag between wikis. I do understand the concern; I’m just trying to figure out the practical effect.

Either way, established sorting will be lost; either the sorting from the source wiki or that from the target wiki. But this strikes me as no different from dragging the Person tag tiddler itself.

If the default were reversed—if we already included the Tag Tiddler in the Tag import—how would you react to @Springer suggesting that we stop doing so? Would you find it an improvement? Or would it look like the introduction of a bug for no good reason? I personally would lean to the latter. This makes me think that the current behavior is incorrect, and the only reason to avoid the change is for backward compatibility.

And I tend to think the preservation of buggy behavior for backward compatibility reasons is almost always a bad idea. That’s why I’m looking to assess the practical implications.

But that can still happen now. With the current structure, if you tag the tiddlers $:/tags/Stylesheet and $:/tags/ViewTemplateBodyFilter as Important and then drag the Important tag to another wiki, you will also overwrite the relevant list fields, colors, etc. for those tiddlers… So the current behavior does not prevent the user from having these problems. But it does add complexity to the sorts of scenarios @Springer is describing.

I should probably stop talking now. I jumped on the bandwagon here, because Springer pointed out a problem I’ve been having, and offered what seemed like an elegant solution. But I quickly realized that I wanted more, and Eric’s code snippet above showed me how to achieve that. I do think this is a good idea, but I won’t push hard for it.

#39

I have, especially for sets of utility macros. Although less often because I have a homegrown version of @pmario bundler plugin, for packages, so I don’t rely on “drag tag pill”, I drag my package instead, and its trivial to include the tag tiddler if needed, But I have to do it explicitly.

This is my solution by way of example.

  • Edit $:/core/ui/TagTemplate dragFilter to read dragFilter={{$:/config/tag-drag-filter}}
  • Create $:/config/tag-drag-filter and enter [all[current]tagging[]] to get the current behaviour and I argue should be and remain default.
  • Alter the above, to include the tag tiddler in all drag and drop actions with [<currentTiddler>] [all[current]tagging[]] as requested by @Springer
  • But personally I would set this to [subfilter{payload-filter}] :else[all[current]tagging[]]
    • And on tags I specifically want to include the tag tiddler (because by design or convention it is safe to do so), add the field payload-filter containing [<currentTiddler>] [all[current]tagging[]]
  • Another approach may be to only add the currentTiddler/tag when it is not a system tiddler, [<currentTiddler>!is[system]] [all[current]tagging[]]

In conclusion with one minor change and the introduction of a config tiddler (name to be determined), any designer can choose what they want to occur, for all or selected tag pills.

  • I would consider removing tiddlers with the done tag if that were important. [<currentTiddler>!is[system]] [all[current]tagging[]!tag[done]] or has [tag[archive]] for dragging out of wiki.

In a very similar way I would introduce

  • Consider changing <$macrocall $name="list-tagged-draggable" tag=<<currentTiddler>>/> to <$macrocall $name="list-tagged-draggable" tag=<<currentTiddler>> subFilter={{!!subFilter}}/> eg; setting on the tag tiddler suibFilter !tag[done]

This contains the modification and config for the above two for testing.
tag config and subfilter.json (1.5 KB)

Or

#40

I don’t know whether I’ve done it regularly, but I’ve done it (mostly, but not always between my own wikis).

This doesn’t seem like an entirely fair equivalency to me. If dragging a tag pill had always included the tag itself, people would have presumably accounted for this behavior in their design decisions, and wikis designed for content sharing might warn about the possibility of overwriting your lists.

To be clear, I do agree that @Springer’s proposed behavior makes sense, and I would indeed have preferred it if tag pills had always worked that way. And I probably won’t be greatly inconvenienced if it is changed going forward. But my gut reaction upon reading her proposal was that it might introduce some compatibility issues for users relying on outdated resources (which is, let’s be honest, most of them, aside from the official site).

This feels like an even less likely scenario than the one I suggested… but I see your point, and I’ll stop playing devil’s advocate.