Re: Systematizing back navigation

[sbaugh@catern.com]

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)