Is there a workaround to this list-after problem? And a wish if there is not

#1

Hi, I was working and at one point I realized that the tabs in the sidebar were in the wrong order.
After some testing to understand where this problem came from I realized that if I have two tiddlers with the same two tags and I change the order of the list field of one of the two tags via drag and drop (doing so manually prevent this issue, but is really inconvenient) all list-before and all ilst-after are deleted.

This is a known thing, as explained in the documentation (for example here) But the fact remains that this fact in many cases causes issues.

Is there a way to make sure this doesn’t happen? I wouldn’t want to remove the function that clears the list-after/list-before fields because I understand why it exists, and in fact it is useful. But maybe something that does the same thing as list-after/list-before without having their name and therefore not being deleted if you use a drag and drop.
If you want to try this, drag and drop this in a TiddlyWiki tiddlers(7).json (611 Bytes)
You can see if you manually edit the list field of the tag Bookmark, nothing happens, but if you use a drag and drop, the one in the tag-pill or even the list-tagged-draggable macro, the list-after/list-before fields are deleted.

If there is no workaround (and it seems to me that there isn't, but I'm not very expert, so maybe there is) I would propose this:

What if, when we define list-after/list-before, we could specify which tags they apply to. (To limit the scope of the list-after/list-before)
For example:

list-after: Tag:"$:/tags/SideBar"-Tiddler

Or maybe we define the tag directly in the field name, I don’t know which could be better.

I don’t know how or how hard could it be to implement, just putting the idea out there.
At this point, if a tag is specified in list-after/list-before it will not be deleted in drag and drop, unless I’m doing a drag and drop operation that modifies the list field of that tag. (e.g. if i have a list-after limited to $:/tags/SideBar, a drag and drop operation inside a <<list-tagged-draggable tag:"$:/tags/SideBar">> or a tag-pill <<tag $:/tags/SideBar>>…)

1 Like
#2

As you have noted, the issue is that the position of tiddlers “Side-A” and “Side-B” in the Sidebar tabs are initially determined by list-before fields (so they occur before the “More” tab). However, if you drag-and-drop to re-order “Side-A” and “Side-B” for the Bookmarks tag, their list-before fields are removed (as necessary), which affects their position in both Bookmarks and $:/tags/Sidebar.

The “fix” is to then ALSO drag-and-drop to re-order the “Side-A” and “Side-B” for the $:/tags/Sidebar tag so that those tiddlers will now be included in the $:/tags/Sidebar!!list field instead of relying upon their respective list-before fields.

From then on, the position of those two tabs can be independantly re-ordered for each tag, without affecting their position in the other tag list.

-e

1 Like
#3

You are right. I probably just complicated things.
By doing as you say, list-after/list-before become redundant in most cases.
I can’t remember from where I got this habit, but from the first day with TiddlyWiki I got into the habit of almost always using list-before without realizing that it is only useful in rare cases.
I’ll remove this habit, thank you very much! In fact the solution to my problem is surprisingly simple. For some applications I never tought outside the list-after/list-before logic

#4

This depends, sometimes you can say list-before and list-after are the normal way and manual reorder the rare case.

  • it tends to be one OR the other.
#5

You are right, depends on the use. I just realized that in my use cases the manual reorder is the one I will use more.

That’s a good way to put it