bug#33258: inhibit-select-window

[martin rudalics]

> 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