From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 33258@debbugs.gnu.org
Subject: bug#33258: inhibit-select-window
Date: Tue, 06 Nov 2018 23:59:48 +0200 [thread overview]
Message-ID: <878t25vpd7.fsf@mail.linkov.net> (raw)
In-Reply-To: <5BE154BC.4080707@gmx.at> (martin rudalics's message of "Tue, 06 Nov 2018 09:45:48 +0100")
> 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?
next prev parent reply other threads:[~2018-11-06 21:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-04 21:17 bug#33258: inhibit-select-window Juri Linkov
2018-11-05 9:34 ` martin rudalics
2018-11-05 21:30 ` Juri Linkov
2018-11-06 8:45 ` martin rudalics
2018-11-06 21:59 ` Juri Linkov [this message]
2018-11-07 9:22 ` martin rudalics
2018-11-07 21:32 ` Juri Linkov
2018-11-08 8:52 ` martin rudalics
2018-11-08 21:56 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878t25vpd7.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=33258@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.