Systematizing back navigation

Systematizing back navigation

[Po Lu]

There is presently a bewildering set of actions taken in response to an
XF86Back key press.  In most buffers, it is equivalent to typing C-x
<left>, switching to the buffer previously displayed in the current
window.  In Help buffers, it navigates to the last Help notice
displayed, and in Info buffers, it navigates to the last node displayed.

Such behavior is confusing because XF86Back cannot be relied on to
restore an earlier state of affairs, be that a previous window
configuration, Info node or current buffer.  To give an example, if the
Info directory is opened, then the node "(elisp)Numeric Conversions",
the scratch buffer, and the Info buffer once more, XF86Back will return
to the Info directory instead of *scratch*.  If XF86Back is pressed
thereafter, Info will print a message to the effect that there is no
previous node in the Info buffer's history without restoring any earlier
window configuration.

Moreover, restoring merely the last buffer to have been selected does
not suffice at times: when I press Back after typing "F" in a Gnus
Article buffer displays a message buffer occupying the whole frame, I am
brought to the Summary buffer, while it is the previous window
configuration incorporating both the Summary and Article buffers that
should be restored in this case.

The object of such keys as XF86Back and its Android analogs is to undo
the effects of the last navigation: a call to display-buffer, switching
to a different window, clicking on a link in an Info buffer, and the
like.  In the first instance, this calls for a unified undo system which
preserves changes to the window configuration, that they might be
reverted when Back is pressed.

As this cannot account for forms of navigation that spare the window
configuration, Info and Help buffers must also make a note of new nodes
visited within this undo system and supply means by which these
alterations can be undone.

There are two shortcomings to this I can't yet address.  If window
configurations are saved, then the selected window is also accounted a
navigation operation and is subject to change when Back is pressed.  Not
only is this unwanted, it also impedes addressing the second
shortcoming, which is that it ought to be possible for the effect of
Back to be limited to a single window, such as by restoring the selected
buffer of that single window rather than that of the window whose
selected buffer is the last to have changed.

Thus instead of implementing and installing a prototype of this at a
venture, I want to ask everyone else's advice, and also for ideas as
regards when and whether this Back mechanism should act as described in
the last paragraph.

TIA.

Re: Systematizing back navigation

[Eli Zaretskii]

On November 21, 2023 5:45:46 AM GMT+02:00, Po Lu <luangruo@yahoo.com> wrote:
> There is presently a bewildering set of actions taken in response to an
> XF86Back key press.  In most buffers, it is equivalent to typing C-x
> <left>, switching to the buffer previously displayed in the current
> window.  In Help buffers, it navigates to the last Help notice
> displayed, and in Info buffers, it navigates to the last node displayed.
> 
> Such behavior is confusing because XF86Back cannot be relied on to
> restore an earlier state of affairs, be that a previous window
> configuration, Info node or current buffer.  To give an example, if the
> Info directory is opened, then the node "(elisp)Numeric Conversions",
> the scratch buffer, and the Info buffer once more, XF86Back will return
> to the Info directory instead of *scratch*.  If XF86Back is pressed
> thereafter, Info will print a message to the effect that there is no
> previous node in the Info buffer's history without restoring any earlier
> window configuration.
> 
> Moreover, restoring merely the last buffer to have been selected does
> not suffice at times: when I press Back after typing "F" in a Gnus
> Article buffer displays a message buffer occupying the whole frame, I am
> brought to the Summary buffer, while it is the previous window
> configuration incorporating both the Summary and Article buffers that
> should be restored in this case.
> 
> The object of such keys as XF86Back and its Android analogs is to undo
> the effects of the last navigation: a call to display-buffer, switching
> to a different window, clicking on a link in an Info buffer, and the
> like.  In the first instance, this calls for a unified undo system which
> preserves changes to the window configuration, that they might be
> reverted when Back is pressed.
> 
> As this cannot account for forms of navigation that spare the window
> configuration, Info and Help buffers must also make a note of new nodes
> visited within this undo system and supply means by which these
> alterations can be undone.
> 
> There are two shortcomings to this I can't yet address.  If window
> configurations are saved, then the selected window is also accounted a
> navigation operation and is subject to change when Back is pressed.  Not
> only is this unwanted, it also impedes addressing the second
> shortcoming, which is that it ought to be possible for the effect of
> Back to be limited to a single window, such as by restoring the selected
> buffer of that single window rather than that of the window whose
> selected buffer is the last to have changed.
> 
> Thus instead of implementing and installing a prototype of this at a
> venture, I want to ask everyone else's advice, and also for ideas as
> regards when and whether this Back mechanism should act as described in
> the last paragraph.
> 
> TIA.
> 
> 

I think you are over-engineering this.  That a key has different bindings in different major modes is nothing new in Emacs.  Moreover, smartphone apps are also inconsistent in what the Back button does in each situation.

So I don't see why we need to worry about this, let alone pretend there's some deep internal issue here.  Perhaps you bumped into some specific situation, and then tried to generalize it too much.  In that case, I suggest to describe the original issue, not its generalizations.

Thanks.

Re: Systematizing back navigation

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I think you are over-engineering this.  That a key has different
> bindings in different major modes is nothing new in Emacs.  Moreover,
> smartphone apps are also inconsistent in what the Back button does in
> each situation.
>
> So I don't see why we need to worry about this, let alone pretend
> there's some deep internal issue here.  Perhaps you bumped into some
> specific situation, and then tried to generalize it too much.  In that
> case, I suggest to describe the original issue, not its
> generalizations.

I did describe three specific scenarios that I come across frequently:
Info, Help and Gnus Article buffers.  Besides those, there are also
pop-ups displayed by the likes of VC,
dired-mouse-find-file-other-window, and virtually every other caller of
display-buffer.  With these, I'd rather Back dismissed the new window
altogether than switch to whatever window previous-buffer selects.

Re: Systematizing back navigation

[Adam Porter]

FWIW, there are various packages related to providing "back button" 
functionality for Emacs, such as my own Dogears.el (dog ears, as in 
folding the corners of a book's pages):

https://github.com/alphapapa/dogears.el

Re: Systematizing back navigation

[Eli Zaretskii]

On November 21, 2023 8:35:26 AM GMT+02:00, Po Lu <luangruo@yahoo.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Perhaps you bumped into some
> > specific situation, and then tried to generalize it too much.  In that
> > case, I suggest to describe the original issue, not its
> > generalizations.
> 
> I did describe three specific scenarios that I come across frequently:
> Info, Help and Gnus Article buffers.  Besides those, there are also
> pop-ups displayed by the likes of VC,
> dired-mouse-find-file-other-window, and virtually every other caller of
> display-buffer.  With these, I'd rather Back dismissed the new window
> altogether than switch to whatever window previous-buffer selects.


IMO, it is entirely reasonable to have Back bound to a command that "goes back" where that makes sense.

Dismissing a window with Back is basically a smartphone thing, so we could bind Back to the function bound to ESC or C-g, but only on Android; doing that on other platforms would be inconsistent with the general behavior of those platforms, and should be avoided, IMO.

Re: Systematizing back navigation

[Dmitry Gutov]

On 21/11/2023 08:57, Eli Zaretskii wrote:
> On November 21, 2023 8:35:26 AM GMT+02:00, Po Lu<luangruo@yahoo.com>  wrote:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>
>>> Perhaps you bumped into some
>>> specific situation, and then tried to generalize it too much.  In that
>>> case, I suggest to describe the original issue, not its
>>> generalizations.
>> I did describe three specific scenarios that I come across frequently:
>> Info, Help and Gnus Article buffers.  Besides those, there are also
>> pop-ups displayed by the likes of VC,
>> dired-mouse-find-file-other-window, and virtually every other caller of
>> display-buffer.  With these, I'd rather Back dismissed the new window
>> altogether than switch to whatever window previous-buffer selects.
> 
> IMO, it is entirely reasonable to have Back bound to a command that "goes back" where that makes sense.

Would it make sense to bind it to xref-go-back globally? With 
mode-specific overrides in place.

> Dismissing a window with Back is basically a smartphone thing, so we could bind Back to the function bound to ESC or C-g, but only on Android; doing that on other platforms would be inconsistent with the general behavior of those platforms, and should be avoided, IMO.

Dismissing the window on 'M-,' if it was just created by 
xref-find-definitions-other-window kind of makes sense to me. Though it 
might mess up the goals the user had set it up for.

OTOH, 'C-x 4 . M-,' currently creates two windows showing the same 
buffer side-by-side, and that's much more easily reached with 'C-x 3'.

Re: Systematizing back navigation

[Dmitry Gutov]

On 21/11/2023 08:39, Adam Porter wrote:
> FWIW, there are various packages related to providing "back button" 
> functionality for Emacs, such as my own Dogears.el (dog ears, as in 
> folding the corners of a book's pages):
> 
> https://github.com/alphapapa/dogears.el

That's a pretty nifty UI.

We've been adding bits from the related packages to the Xref 
back/forward functionality, but it's still bare-bones in comparison.

Re: Systematizing back navigation

[sbaugh]

Po Lu <luangruo@yahoo.com> writes:
> The object of such keys as XF86Back and its Android analogs is to undo
> the effects of the last navigation: a call to display-buffer, switching
> to a different window, clicking on a link in an Info buffer, and the
> like.  In the first instance, this calls for a unified undo system which
> preserves changes to the window configuration, that they might be
> reverted when Back is pressed.
>
> As this cannot account for forms of navigation that spare the window
> configuration, Info and Help buffers must also make a note of new nodes
> visited within this undo system and supply means by which these
> alterations can be undone.

This sounds like a very interesting and useful system!  I would love to
have a single key which handles all the different forms of going back,
including xref-go-back and others.

This is also a very familiar mode of interaction from web browsers,
using back and forward to navigate across different web sites with
different content and different applications, not just within one
application.

Thought: Could we also support "go forward"?  That would make it more
clear that this is not just an Android thing.  And forward navigations
is supported by all these individual things, e.g.:

- Info-history-forward
- help-go-forward
- xref-go-forward
- winner-redo

Thought: Supporting xref-go-back will mean that "go back" might just
move to a different position within the current buffer rather than
necessarily changing buffer or buffer contents.

Thought: global-mark-ring might be part of a universal go-back button.

> There are two shortcomings to this I can't yet address.  If window
> configurations are saved, then the selected window is also accounted a
> navigation operation and is subject to change when Back is pressed.

It looks like, from some brief experimentation, that winner-mode doesn't
save the selected window.  Maybe you can do whatever winner-mode is
doing?

But also, I'm not actually sure this is a shortcoming.  It seems like
changing selected window might be desirable behavior.  See below.

> Not only is this unwanted, it also impedes addressing the second
> shortcoming, which is that it ought to be possible for the effect of
> Back to be limited to a single window, such as by restoring the
> selected buffer of that single window rather than that of the window
> whose selected buffer is the last to have changed.

I think we should limit Back to a single tab/frame, not to a single
window.  I think in practice that would be what we'd want.

In environments like GNOME/KDE/Windows/MacOS/Android, each application
runs in its own window, and a "Back" button (if the application provides
it) will operate on that individual window.

Those environments might let you display two applications next to each
other, in two separate windows, and the Back button will still operate
on the individual application.

But in Emacs, there isn't a one-to-one relationship between "window" and
"application".  Emacs packages make a lot of use of multi-window
behavior.  For example, xref pops up a window with matches, and gnus
makes various multi-window layouts.

So it makes sense for the Back button to operate on an entire window
configuration, within a specific tab or frame.

And if a user wants to have two "applications", like gnus and text
editing, and have Back operate only on one at a time, they can use two
tabs.  If the user wants gnus and editing buffers displayed next to each
other, they can put two frames next to each other.

(It would be kind of nice to have a uniform way to subdivide a frame so
that gnus didn't take over the entire frame; if we had such a way to
subdivide the frame, then maybe Back would operate on that unit.  But
that's for the future)

Re: Systematizing back navigation

[Juri Linkov]

> Thus instead of implementing and installing a prototype of this at a
> venture, I want to ask everyone else's advice, and also for ideas as
> regards when and whether this Back mechanism should act as described in
> the last paragraph.

I'm afraid it's a quite hopeless endeavor to find such a common denominator
that would satisfy even a small fraction of users since endless number of
navigation spaces might be active at the same time.  Much more than even
possible for next-error navigation where we struggled to find a way
to switch between available navigation spaces.  For example, for the
Back button my preference is to navigate in the file system: in a file buffer
typing the Back button goes to the Dired buffer with point on that file name
when the file was visited from Dired, then the next Back button goes up
to the parent directory, etc. like in a typical File Manager.