GNU bug report logs - #33258
inhibit-select-window

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 33258 <at> debbugs.gnu.org
Subject: bug#33258: inhibit-select-window
Date: Tue, 06 Nov 2018 23:59:48 +0200

> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.