Re: Systematizing back navigation

[Eli Zaretskii <eliz@gnu.org>]

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.