Subject: bug#33258: inhibit-select-window

From: martin rudalics <[email-masked]>
Date: Tue, 06 Nov 2018 09:45:48 +0100

> This feature is intended only for user customization in display-buffer-alist,
 > not in the args of pop-to-buffer.  It makes no sense for a programmer
 > to use (inhibit-select-window . t) in the args of pop-to-buffer when
 > a programmer can simply replace pop-to-buffer with a display-buffer call.

Sure.  I nowhere assumed that the caller would add such an entry.

 > However, if an user is annoyed by always selecting a window of
 > a displayed buffer by default, and such customization doesn't
 > cause a bad side effect by not making the displayed buffer the current,
 > and this is true in 99% cases, then we should be proud to make
 > the users happier.

By providing 'pop-to-buffer' we signed a contract that if a program
calls it, it does "Display buffer specified by BUFFER-OR-NAME and
select its window".  This means that when 'pop-to-buffer' returns the
buffer, the calling program can be sure that a window showing that
buffer is selected and the buffer is current.  If a user is allowed to
override that behavior by keeping, for example, the previously
selected window selected and its buffer current, then 'pop-to-buffer'
would have violated the contract and we will get into troubles in due
time.

I think there's a simple way out.  The user provides an
'inhibit-select-window' request via a 'display-buffer-alist' (or
'display-buffer-base-action') entry as you suggested.
'display-buffer', by itself, honors that request iff the caller, in
the ACTION argument, has provided an 'allow-inhibit-select-window'
alist entry (much like your earlier 'allow-no-window' entries)
indicating its willingness to live with the fact that the window does
not get selected.

This way, any caller like 'vc-diff' can make provisions for the case
that the window is not selected.  If, as you say, 99% of the callers
are prepared for that case, there should not be any problems
converting most callers of 'pop-to-buffer' to include such an entry in
their action alists.  But we have more than 99 'pop-to-buffer' calls
in our sources and there are still more in the rest of this world.

 > force-select-window looks good, also possible is one of these names:
 >
 >    (pop-to-buffer . t)
 > or
 >    (pop-up-window . t)
 >
 > as a reference to the related feature.

We could convert 'pop-to-buffer' calls to 'display-buffer' calls with
a 'force-select-window' t alist entry.  Users could override that with
a 'force-select-window' nil entry.  This would be the contrapositive
of the 'inhibit-select-window' approach.

martin