[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33258: inhibit-select-window
From: |
martin rudalics |
Subject: |
bug#33258: inhibit-select-window |
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
- bug#33258: inhibit-select-window, Juri Linkov, 2018/11/04
- bug#33258: inhibit-select-window, martin rudalics, 2018/11/05
- bug#33258: inhibit-select-window, Juri Linkov, 2018/11/05
- bug#33258: inhibit-select-window,
martin rudalics <=
- bug#33258: inhibit-select-window, Juri Linkov, 2018/11/06
- bug#33258: inhibit-select-window, martin rudalics, 2018/11/07
- bug#33258: inhibit-select-window, Juri Linkov, 2018/11/07
- bug#33258: inhibit-select-window, martin rudalics, 2018/11/08
- bug#33258: inhibit-select-window, Juri Linkov, 2018/11/08