bug#67993: Selecting buffer automatically

[martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

 >> In 'display-buffer' first save the selected window as
 >> old-selected-window, display the buffer and in your code select
 >> old-selected-window instead of (old-selected-window).
 >
 > Unfortunately, this is not so easy to do.  'old-selected-window'
 > should be reinitialized before the next command is executed.

Why?  As I imagine it, it would be let-bound in 'display-buffer'.

 > So by definition 'old-selected-window' should contain
 > the window that was selected before the current command
 > was executed.  I have no idea how to do this without hooks.

Hmmm... I have problems to see what the "current command" is.  One and
the same command may contain multiple invocations of 'display-buffer'.
I thought you wanted a 'select-window' entry to be handled separately by
each of them.  Otherwise, IIUC the entry provided by the last invocation
would prevail any entries provided by previous invocations.  How would
you explain that to a user?

If you want 'old-selected-window' to denote "some" state before the
"current command", the function 'old-selected-window' might be a better
choice than a variable you bind in 'display-buffer' (but note that
redisplay may occur in the middle of executing a command).

But if you want to interpret "current command" more strictly, you need a
separate variable, say 'pre-command-selected-window' that you always set
in 'pre-command-hook' and consult (and maybe reset) in
'post-command-hook'.

 > 'pop-to-buffer' can't be changed because (select-window . t)
 > should be handled only at the end of the current command.

Are your sure that you do not somewhat arbitrarily restrict the scope of
this feature?  What if (select-window . t) were to be handled in a call
from within a timer?  Would you ignore it?

 > So this also need to run 'select-frame' in post-command-hook.

'select-frame-set-input-focus' maybe.  Or, what's worse, undo the
consequences of a preceding 'select-frame-set-input-focus' call
triggered by 'pop-to-buffer'.  That's why any such 'select-window' call
(or its avoidance) you propose would be better handled within
'display-buffer' and not later in a 'post-command-hook'.

martin