When closing, navigate to previous tiddler

[twMat]

Note 1: I made a plugin for this: https://scrollback.tiddlyhost.com/ - (I still think it should be a core feature though)

Note 2: This post has been revised to reflect insights and clarifications from the succeeding ~14 posts.

Problem scenario
Some common tiddlers are open. You're reading one of them, tiddler A, and inside it click a tiddler link or perhaps create a child, which opens and sets focus to a new tiddler, B, below A. ...but when you then close B, you don't get back to tiddler A. Instead you're presented the tiddler below, tiddler C!

This is typically distracting because A and B had a certain context - and now a possibly completely different matter is scrolled into view. The context is broken as is the users mental chronology of past events.

Proposal
Closing or Deleting a tiddler, via its toolbuttons, should by default shift focus to the tiddler that's listed before the current on in the StoryList!!list. (For default TW this means the tiddler above, not the tiddler below.)

[pmario]

Some common tiddlers are open. You're reading one of them, tiddler A, and inside it click a tiddler link or perhaps create a child,

There is a fundamental difference between navigating "above / below" and "create a new tiddler". New tiddlers are always created below the actual tiddler.

[pmario]

I think this highly depends on a users preferences and the workflow at a given time.

Consider my real live workflow:

Open Tiddler: SomeContentWithLinks

• open a link with CTRL-click-link ... A
  • tiddler A is opened below, but focus isn't moved
• open a second link with CTRL-click-link .. B
  • tiddler B is opened below, but focus isn't moved ... because I want to finish reading SomeContentWithLinks and then I'll read the others.
• I go down to B and read it. ... I'm finished so I close it .. to read A

... Can you imagine, how "distracted" I am, if the SomeContentWithLinks jumps into view by default now?

I know that I need to read the "child" tiddlers in reverse order. So my proposal would be completely different, according to my workflow. ... But depending, what I do, the workflow varies. ...

[pmario]

@twMat I did create a version, as you describe it for testing only see: index.zip

If you open the TW it makes sense. ... But if the tiddler with the link is small, and low in the list, the behaviour also feels starnge. .. at least for me.

[pmario]

For me a new global setting eg: "Closing a tiddler selects the tiddler above" would make sense. It would be independent from the other settings.

[twMat]

Consider my real live workflow:
[...]

Well, as you mention, you're reading the child tiddlers in reverse. If you wanted to read them in order and went down further to read A first then my proposal would actually bring you to the desired B after closing A.

However, my main point; regardless of order the children were read in, when you eventually close the last remaining child, you currently don't get to the parent but instead some unrelated tiddler X. That is distracting.

@twMat I did create a version, as you describe it for testing only see: index.zip

Ha! That seems to work really well! And, sure, having it as a new global setting is a route - but IMO my proposal makes more sense than the current default behaviour.

[Jermolene]

For me a new global setting eg: "Closing a tiddler selects the tiddler above" would make sense. It would be independent from the other settings.

But what, exactly, does "selects the tiddler above" mean?

[Jermolene]

Bear in mind that using the "Open" sidebar tab it is possible to close tiddlers without them being visible

[twMat]

Bear in mind that using the "Open" sidebar tab it is possible to close tiddlers without them being visible

Good point, I've updated the OP to limit it to when the tiddler is closed using the close-tiddler-tool X button.

[pmario]

Bear in mind that using the "Open" sidebar tab it is possible to close tiddlers without them being visible

I know and that makes it complicated, since the existing mechanism imo has no chance to know this.

[tobibeer]

@pmario, since your initial behaviour of opening tids in the background is triggered via some non-default CTRL+Click... so your closing a tiddler could also be non-default, e.g. CTRL+Close

I don't think "above" is quite what we're after but rather "the previous title in the history".

[twMat]

@tobibeer

I don't think "above" is quite what we're after but rather "the previous title in the history".

To clarify, I think the idea is to set focus on the title in $:/StoryList that appears before the one being closed (adjusted for if the user has set some Tiddler Opening Behaviour)

[pmario]

non-default CTRL+Click. ...

Ctrl+Click is there since ages. .. It's default behaviour, to open tiddlers, without scrolling.

[pmario]

To clarify, I think the idea is to set focus on the title in $:/StoryList that appears before the one being closed (adjusted for if the user has set some Tiddler Opening Behaviour)

That's exactly, what the version in the .zip file does. ... But it also does the scrolling, if you close a tiddler form the "Open" sidebar. ... Which can't be detected at the moment. .. But for me it actually works better, than the default behaviour, since it scrolls to the top of the tiddler. ...

I'm not sure if we can have CTRL-close to close a tiddler and avoid scrolling.

[twMat]

Just realized there's no need to try to figure out where the tm-close comes from. We know that only(?) the tiddlers own local close button is where we want the OP idea to play out. ...so the focus should be there, right?

The following works. Is there anything principally wrong or inappropriate with it?

title: $:/core/ui/Buttons/close
tags: $:/tags/ViewToolbar
text:
\define neighbour()
<$list filter="[list[$:/StoryList!!list]before<current>]"/>
\end
<$button message="tm-close-tiddler" tooltip={{$:/language/Buttons/Close/Hint}} aria-label={{$:/language/Buttons/Close/Caption}} class=<<tv-config-toolbar-class>>>
<$wikify name="current" text=<<currentTiddler>>>
<$wikify name="goto" text=<<neighbour>>>
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{$:/core/images/close-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text={{$:/language/Buttons/Close/Caption}}/></span>
</$list>
<$action-navigate $to=<<goto>>/>
</$wikify>
</$wikify>
</$button>

Not sure how to make it accommodate to
$:/config/Navigation/openLinkFromInsideRiver which has values below or above.

It would be cool if the below/above value could somehow be used directly as if it was the before/after filter operator in [list[$:/StoryList!!list]before<current>] ...or maybe that's too coupled coding (if I'm using the term right ...anyway, it would be cool!). I recall seeing something by @tobibeer where he redefined some key term to mean something else but don't remember where/how...

[twMat]

@Jermolene - assuming a properly coded solution that only concerns the local tiddlers close button - would this be accepted for core? Or is there a problem with the concept to begin with?

[Jermolene]

Hi @twMat there are quite a few issues that would need working through.

For example, the implementation above is specific to the close button in the toolbar, and the logic isn't invoked if the tiddler is closed by other means (eg, the "close" button in the "open" sidebar). Neither of course would one necessarily want the logic invoked in that situation; what if the tiddler being closed isn't currently scrolled into view?

Personally, I think it makes more sense to extend the story logic with the sense of a "currently focused tiddler" that can be controlled with the keyboard.

[twMat]

@Jermolene - in order to solve the issue, we would thus have to specify exactly when one would want the logic invoked. In your opinion, when is this?

Personally, I think it makes more sense to extend the story logic with the sense of a "currently focused tiddler" that can be controlled with the keyboard.

Cool. But the question of which tiddler to automatically give focus to after the current is closed still remains, no?

[Jermolene]

Cool. But the question of which tiddler to automatically give focus to after the current is closed still remains, no?

The trouble is that there is no concept of "focus" in TW5 at the moment, just that of navigating to a new tiddler. As discussed above, using navigate to jump to a new tiddler after a closure will sometimes have unexpected side-effects. Plus I think your logic really only works within the "classic" storyview.

But more broadly, whatever defaults we chose for what happens when you close a tiddler, the behaviour is going to be wrong for some users. The ability to navigate with the keyboard would give the user a direct way to rapidly manipulate the story river.

[pmario]

The ability to navigate with the keyboard would give the user a direct way to rapidly manipulate the story river.

As long as it's not the tab key, which is used for navigation, I'm fine.

[twMat]

I have used this close button now for some two years.

<$button message="tm-close-tiddler" tooltip={{$:/language/Buttons/Close/Hint}} aria-label={{$:/language/Buttons/Close/Caption}} class=<<tv-config-toolbar-class>>>
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{$:/core/images/close-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text={{$:/language/Buttons/Close/Caption}}/></span>
</$list>
<$action-navigate $to={{{ [list[$:/StoryList!!list]before<currentTiddler>] }}}/>
</$button>

Equivalent for the delete button.

It works perfectly and does, in deed, give a much better UX. Performance instrumentation show insignificant difference (both plus and minus a few ms here and there).

[Tejeev]

@twMat You are a freaking lifesaver... I honestly found the default behavior so annoying and disorienting as to be the largest disruption in my workflow... It's dumb I know, but I can't understand why this feature request is not just a configurable option?

I added <$action-navigate $to={{{ [list[$:/StoryList!!list]before<currentTiddler>] }}}/> to my close button and that's all it took to give TW the polish it needed to really become my wiki of choice... .unfortunately this sort of breaks upgrading.. guess I'll just document the change in my wiki 🤦🏾

@Jermolene @pmario would it not just make more sense to offer a checkbox in the theme configuration tiddler to set <$action-navigate $to={{{ [list[$:/StoryList!!list]before<currentTiddler>] }}}/> in the close button (rather than try to figure out some buggy logic for when to do it automatically and account for when it would break other users workflows?).

[twMat]

... I honestly found the default behavior so annoying and disorienting as to be the largest disruption in my workflow...

I frankly wonder how can it not be annoying to have a typically irrelevant tiddler appear instead of the one you were previously at? Maybe they have very different use cases where each tiddler is either totally unconnected or, the opposide, the tiddlers are all totally relevant to one another, so an arbitrary tiddler doesn't disrupt their train-of-thought. Or maybe their workflow is to very consistently close a tiddler right after working with it so that they don't have multiple tiddlers in the river? (I'd guess there's an overlap with people who have very few browser tabs open.)

Had I remembered, I should have flagged this for 5.1.23 but now I'm hoping it can be dealt with for .24 (@Jermolene )

[rmunn]

By far the simplest way to solve this would be to change the default value of $:/config/Navigation/openLinkFromInsideRiver from "below" to "above". Then any tiddler that you click on will open above the current tiddler (if it wasn't open already), and closing it will slide the previous tiddler back into view. No code changes needed, just a simple config change that apparently many people don't realize exists.

[twMat]

@rmunn - that's a good point but IMO it's not fully satisfactory. (The resulting story river then, of course, doesn't read well from top bottom for the times when one does want that, e.g permalinks.)

[Tejeev]

I'm with @twMat on this one. I find it far easier to use his little workaround than to retrain my mind to read a tiddler from top to bottom and link tiddlers from bottom to top, but it's worth noting this as a viable workaround for others until there is the option to flip this close behaviour in TW as a builtin option.

For others coming here the best solutions are:

1. Edit the close button as per: When closing, navigate to previous tiddler #2776 (comment)
2. Have links open tiddlers above rather than below the current tiddler: When closing, navigate to previous tiddler #2776 (comment)

[twMat]

I still insist that the requested behaviour, i.e to navigate to previous tiddler in StoryList, is totally superior to default.

Would it be possible to add an action param to the close and delete buttons, to allow for actions defined elsewhere? I've had to schlepp around my crude core overwrites outlined here above for several years now.

[twMat]

OP is revised, most importantly to inform about the plugin I made. The request is as valid as ever but it touches on the more general need, as noted by @saqimtiaz apropos that it would be desirable to remotely hook into the close- and delete button core tiddlers rather than overwriting them:

Implementing anything like this is intricately tied with the work of opening up the core to be expressed more so in wikitext and thus hackable. In particular we need to provide affordances to replace the current JavaScript only hooks 1 with equivalent wikitext based affordances. This is a non-trivial amount of work. Parameterized transclusions are the first step in this direction.

Trying to address the expressed needs independently of implementing wikitext affordances for hooks would likely lead to two similar but conflicting mechanisms for customizing core behaviour.

With this in mind, and also considering the obvious lack for support for the OP, I'm closing this issue.

Thank you, everyone who participated.