[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33258: inhibit-select-window
From: |
Juri Linkov |
Subject: |
bug#33258: inhibit-select-window |
Date: |
Tue, 06 Nov 2018 23:59:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
> 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.
You are right. I think we can reliably restore an originally selected
window only at the end of the command, somewhere at the time when the
post-command-hook is called.
A prototype that demonstrates a problem-free implementation is:
(advice-add 'vc-diff :around
(lambda (orig-fun &rest args)
(save-selected-window
(apply orig-fun args)))
'((name . inhibit-select-window)))
A question is how to do something like this using 'display-buffer-alist'
with 'inhibit-select-window'.
> 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.
This is a huge task to inspect all existing pop-to-buffer calls
and to add 'allow-inhibit-select-window' where it's safe, or to change
the existing code to be safe (if this is possible at all).
>> 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.
Does this have the same problem of not making the displayed buffer
current?
- 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, 2018/11/06
- bug#33258: inhibit-select-window,
Juri Linkov <=
- 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