bug#67993: Selecting buffer automatically

bug#67993: Selecting buffer automatically

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

[From emacs-devel]
>>> I believe this should be customizable with something like
>>> 
>>>  (setopt display-buffer-alist
>>>   '(("\\*Compile-Log\\*" nil (select-window . t))))
>>
>> Thank you for the advice, but I tried this and it didn't work.
>> *Compile-log* buffer isn't selected.
>
> This feature was discussed in bug#33258 and bug#46034,
> but not yet implemented.  It should be easy to implement
> exactly the same way as 'windmove-display-in-direction'
> selects the old or new window in 'post-command-hook'.
> Ok, I will post a patch to bug-gnu-emacs.

Here is the patch that allows using (select-window . t) in display-buffer-alist
to select the displayed window, and (select-window . nil) to deselect windows
selected by such functions as pop-to-buffer:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: select-window.patch --]
[-- Type: text/x-diff, Size: 914 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 40070a4d929..fad95601a55 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7851,6 +7856,16 @@ display-buffer
       (while (and functions (not window))
         (setq window (funcall (car functions) buffer alist)
               functions (cdr functions)))
+      (when-let ((select-window (assq 'select-window alist)))
+        (letrec ((postfun
+                  (lambda ()
+                    (if (cdr select-window)
+                        (when (window-live-p window)
+                          (select-window window))
+                      (when (window-live-p (old-selected-window))
+                        (select-window (old-selected-window))))
+                    (remove-hook 'post-command-hook postfun))))
+          (add-hook 'post-command-hook postfun)))
       (and (windowp window) window))))
 
 (defun display-buffer-other-frame (buffer)

bug#67993: Selecting buffer automatically

[Juri Linkov]

Martin, do you agree with this change?
If ok, then I could update the documentation as well.

>>>> I believe this should be customizable with something like
>>>>
>>>>  (setopt display-buffer-alist
>>>>   '(("\\*Compile-Log\\*" nil (select-window . t))))
>>>
>>> Thank you for the advice, but I tried this and it didn't work.
>>> *Compile-log* buffer isn't selected.
>>
>> This feature was discussed in bug#33258 and bug#46034,
>> but not yet implemented.  It should be easy to implement
>> exactly the same way as 'windmove-display-in-direction'
>> selects the old or new window in 'post-command-hook'.
>> Ok, I will post a patch to bug-gnu-emacs.
>
> Here is the patch that allows using (select-window . t) in display-buffer-alist
> to select the displayed window, and (select-window . nil) to deselect windows
> selected by such functions as pop-to-buffer:
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 40070a4d929..fad95601a55 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -7851,6 +7856,16 @@ display-buffer
>        (while (and functions (not window))
>          (setq window (funcall (car functions) buffer alist)
>                functions (cdr functions)))
> +      (when-let ((select-window (assq 'select-window alist)))
> +        (letrec ((postfun
> +                  (lambda ()
> +                    (if (cdr select-window)
> +                        (when (window-live-p window)
> +                          (select-window window))
> +                      (when (window-live-p (old-selected-window))
> +                        (select-window (old-selected-window))))
> +                    (remove-hook 'post-command-hook postfun))))
> +          (add-hook 'post-command-hook postfun)))
>        (and (windowp window) window))))
>
>  (defun display-buffer-other-frame (buffer)

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Martin, do you agree with this change?
 > If ok, then I could update the documentation as well.

The following looks like a glitch:

 >> +                      (when (window-live-p (old-selected-window))
 >> +                        (select-window (old-selected-window))))

is supposed to select the window selected the last time we ran window
change functions.  Now consider the following scenario:

- Redisplay runs the window change functions and sets the old selected
   window.

- An application changes the selected window.

- 'display-buffer' gets called with a (select-window . nil) entry.  The
   call will select the window selected at last redisplay.

So I think that calling 'old-selected-window' here is not TRT.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

>> Martin, do you agree with this change?
>> If ok, then I could update the documentation as well.
>
> The following looks like a glitch:
>
>>> +                      (when (window-live-p (old-selected-window))
>>> +                        (select-window (old-selected-window))))
>
> is supposed to select the window selected the last time we ran window
> change functions.  Now consider the following scenario:
>
> - Redisplay runs the window change functions and sets the old selected
>   window.
>
> - An application changes the selected window.
>
> - 'display-buffer' gets called with a (select-window . nil) entry.  The
>   call will select the window selected at last redisplay.
>
> So I think that calling 'old-selected-window' here is not TRT.

Could you suggest an alternative to 'old-selected-window'
to select the original window that was selected before
the current command?

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Could you suggest an alternative to 'old-selected-window'
 > to select the original window that was selected before
 > the current command?

In 'display-buffer' first save the selected window as
old-selected-window, display the buffer and in your code select
old-selected-window instead of (old-selected-window).

Better, rename "select-window" to "window-to-select" so grepping won't
confuse it with a 'select-window' call and allow for an arbitrary window
(or even buffer, but there could be two windows showing the same buffer)
to use as the finally selected window in 'display-buffer'.  And maybe
have 'pop-to-buffer' and friends pass (select-window . t) instead of
calling 'select-window' themselves and think of what has to happen when
the window made or used by 'display-buffer' is on another frame that
should be (de-)selected.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

>> Could you suggest an alternative to 'old-selected-window'
>> to select the original window that was selected before
>> the current command?
>
> In 'display-buffer' first save the selected window as
> old-selected-window, display the buffer and in your code select
> old-selected-window instead of (old-selected-window).

Unfortunately, this is not so easy to do.  'old-selected-window'
should be reinitialized before the next command is executed.

So by definition 'old-selected-window' should contain
the window that was selected before the current command
was executed.  I have no idea how to do this without hooks.

> Better, rename "select-window" to "window-to-select" so grepping won't
> confuse it with a 'select-window' call and allow for an arbitrary window
> (or even buffer, but there could be two windows showing the same buffer)
> to use as the finally selected window in 'display-buffer'.  And maybe
> have 'pop-to-buffer' and friends pass (select-window . t) instead of
> calling 'select-window' themselves

'pop-to-buffer' can't be changed because (select-window . t)
should be handled only at the end of the current command.

> and think of what has to happen when the window made or used by
> 'display-buffer' is on another frame that should be (de-)selected.

So this also need to run 'select-frame' in post-command-hook.

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> In 'display-buffer' first save the selected window as
 >> old-selected-window, display the buffer and in your code select
 >> old-selected-window instead of (old-selected-window).
 >
 > Unfortunately, this is not so easy to do.  'old-selected-window'
 > should be reinitialized before the next command is executed.

Why?  As I imagine it, it would be let-bound in 'display-buffer'.

 > So by definition 'old-selected-window' should contain
 > the window that was selected before the current command
 > was executed.  I have no idea how to do this without hooks.

Hmmm... I have problems to see what the "current command" is.  One and
the same command may contain multiple invocations of 'display-buffer'.
I thought you wanted a 'select-window' entry to be handled separately by
each of them.  Otherwise, IIUC the entry provided by the last invocation
would prevail any entries provided by previous invocations.  How would
you explain that to a user?

If you want 'old-selected-window' to denote "some" state before the
"current command", the function 'old-selected-window' might be a better
choice than a variable you bind in 'display-buffer' (but note that
redisplay may occur in the middle of executing a command).

But if you want to interpret "current command" more strictly, you need a
separate variable, say 'pre-command-selected-window' that you always set
in 'pre-command-hook' and consult (and maybe reset) in
'post-command-hook'.

 > 'pop-to-buffer' can't be changed because (select-window . t)
 > should be handled only at the end of the current command.

Are your sure that you do not somewhat arbitrarily restrict the scope of
this feature?  What if (select-window . t) were to be handled in a call
from within a timer?  Would you ignore it?

 > So this also need to run 'select-frame' in post-command-hook.

'select-frame-set-input-focus' maybe.  Or, what's worse, undo the
consequences of a preceding 'select-frame-set-input-focus' call
triggered by 'pop-to-buffer'.  That's why any such 'select-window' call
(or its avoidance) you propose would be better handled within
'display-buffer' and not later in a 'post-command-hook'.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

>>> In 'display-buffer' first save the selected window as
>>> old-selected-window, display the buffer and in your code select
>>> old-selected-window instead of (old-selected-window).
>>
>> Unfortunately, this is not so easy to do.  'old-selected-window'
>> should be reinitialized before the next command is executed.
>
> Why?  As I imagine it, it would be let-bound in 'display-buffer'.

Ah, indeed, this is even better.  This shows differences
from the previous patch:

diff --git a/lisp/window.el b/lisp/window.el
index 5c3e68f04eb..f34b6d625c6 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7859,13 +7859,14 @@ display-buffer
         (setq window (funcall (car functions) buffer alist)
               functions (cdr functions)))
       (when-let ((select-window (assq 'select-window alist)))
-        (letrec ((postfun
+        (letrec ((old-selected-window (selected-window))
+                 (postfun
                   (lambda ()
                     (if (cdr select-window)
                         (when (window-live-p window)
                           (select-window window))
-                      (when (window-live-p (old-selected-window))
-                        (select-window (old-selected-window))))
+                      (when (window-live-p old-selected-window)
+                        (select-window old-selected-window)))
                     (remove-hook 'post-command-hook postfun))))
           (add-hook 'post-command-hook postfun)))
       (and (windowp window) window))))

>> So by definition 'old-selected-window' should contain
>> the window that was selected before the current command
>> was executed.  I have no idea how to do this without hooks.
>
> Hmmm... I have problems to see what the "current command" is.  One and
> the same command may contain multiple invocations of 'display-buffer'.
> I thought you wanted a 'select-window' entry to be handled separately by
> each of them.  Otherwise, IIUC the entry provided by the last invocation
> would prevail any entries provided by previous invocations.  How would
> you explain that to a user?
>
> If you want 'old-selected-window' to denote "some" state before the
> "current command", the function 'old-selected-window' might be a better
> choice than a variable you bind in 'display-buffer' (but note that
> redisplay may occur in the middle of executing a command).

I guess the variable above should be fine.

> But if you want to interpret "current command" more strictly, you need a
> separate variable, say 'pre-command-selected-window' that you always set
> in 'pre-command-hook' and consult (and maybe reset) in
> 'post-command-hook'.

This would be more troublesome.

>> 'pop-to-buffer' can't be changed because (select-window . t)
>> should be handled only at the end of the current command.
>
> Are your sure that you do not somewhat arbitrarily restrict the scope of
> this feature?  What if (select-window . t) were to be handled in a call
> from within a timer?  Would you ignore it?

It would be a good design to ignore (select-window . t) from a hook.
When windows pop up at random time while user is typing, this is
too dangerous to allow.  I remember such annoying popups as e.g.
with a button "[D]elete" with the shortcut "D" while
you are typing a text that contains "D" ;-)

>> So this also need to run 'select-frame' in post-command-hook.
>
> 'select-frame-set-input-focus' maybe.  Or, what's worse, undo the
> consequences of a preceding 'select-frame-set-input-focus' call
> triggered by 'pop-to-buffer'.

Ok, I will try to save and restore 'old-selected-frame' as well.

> That's why any such 'select-window' call (or its avoidance) you
> propose would be better handled within 'display-buffer' and not later
> in a 'post-command-hook'.

No way to call 'select-window' immediately, because this will
break too many functions that expect a window to be selected
from the previous call of pop-to-buffer until the command
is finished.

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> That's why any such 'select-window' call (or its avoidance) you
 >> propose would be better handled within 'display-buffer' and not later
 >> in a 'post-command-hook'.
 >
 > No way to call 'select-window' immediately, because this will
 > break too many functions that expect a window to be selected
 > from the previous call of pop-to-buffer until the command
 > is finished.

Do you mean that if I have two 'pop-to-buffer' calls within one and the
same command, the first one has a (select-window . nil) entry and the
second one no such entry, then the entry from the first call will cause
the window from the second call to get deselected?  If so, then this
deserves a special explanation in the manual.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

>>> That's why any such 'select-window' call (or its avoidance) you
>>> propose would be better handled within 'display-buffer' and not later
>>> in a 'post-command-hook'.
>>
>> No way to call 'select-window' immediately, because this will
>> break too many functions that expect a window to be selected
>> from the previous call of pop-to-buffer until the command
>> is finished.
>
> Do you mean that if I have two 'pop-to-buffer' calls within one and the
> same command, the first one has a (select-window . nil) entry and the
> second one no such entry, then the entry from the first call will cause
> the window from the second call to get deselected?  If so, then this
> deserves a special explanation in the manual.

This is what I see with the current patch:

1.
(let ((display-buffer-alist '(("1" nil (select-window . nil)))))
  (delete-other-windows) (split-window) (split-window) (balance-windows)
  (pop-to-buffer (get-buffer-create "1"))
  (pop-to-buffer (get-buffer-create "2")))

then the original window remains selected.

2.
(let ((display-buffer-alist '(("2" nil (select-window . nil)))))
  (delete-other-windows) (split-window) (split-window) (balance-windows)
  (pop-to-buffer (get-buffer-create "1"))
  (pop-to-buffer (get-buffer-create "2")))

then the window with "1" is selected after the command finishes.

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > This is what I see with the current patch:
 >
 > 1.
 > (let ((display-buffer-alist '(("1" nil (select-window . nil)))))
 >    (delete-other-windows) (split-window) (split-window) (balance-windows)
 >    (pop-to-buffer (get-buffer-create "1"))
 >    (pop-to-buffer (get-buffer-create "2")))
 >
 > then the original window remains selected.

But this means that the customization for "1" affects popping to "2".
If this is the intended effect, it should be documented.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

>> This is what I see with the current patch:
>>
>> 1.
>> (let ((display-buffer-alist '(("1" nil (select-window . nil)))))
>>    (delete-other-windows) (split-window) (split-window) (balance-windows)
>>    (pop-to-buffer (get-buffer-create "1"))
>>    (pop-to-buffer (get-buffer-create "2")))
>>
>> then the original window remains selected.
>
> But this means that the customization for "1" affects popping to "2".
> If this is the intended effect, it should be documented.

But actually the customization for "1" doesn't affect popping to "2"
because pop-to-buffer still selects windows and creates such layout:

  *scratch*
  Buffer "1"
  Buffer "2"

Only post-command-hook selects the original window afterwards
instead of leaving the buffer "2" selected.

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > But actually the customization for "1" doesn't affect popping to "2"
 > because pop-to-buffer still selects windows and creates such layout:
 >
 >    *scratch*
 >    Buffer "1"
 >    Buffer "2"
 >
 > Only post-command-hook selects the original window afterwards
 > instead of leaving the buffer "2" selected.

And if the customization for "2" meant to select the window, the final
outcome will depend on whichever (de-)selection comes last in the
'post-command-hook'.  You should at least document that in the manual.
It looks pretty fragile to me.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

>> But actually the customization for "1" doesn't affect popping to "2"
>> because pop-to-buffer still selects windows and creates such layout:
>>
>>    *scratch*
>>    Buffer "1"
>>    Buffer "2"
>>
>> Only post-command-hook selects the original window afterwards
>> instead of leaving the buffer "2" selected.
>
> And if the customization for "2" meant to select the window, the final
> outcome will depend on whichever (de-)selection comes last in the
> 'post-command-hook'.  You should at least document that in the manual.
> It looks pretty fragile to me.

A practical use of this feature is for commands that display a single buffer
that is an overwhelming majority of the commands.

However, the name 'select-window' would be too confusing for users
because based on such name they will expect that it will select
the window immediately after it's displayed.

Therefore I propose to rename it to the less ambiguous name
'post-command-select-window'.  Of course it should be documented in
any case, but this will help the users who never read the documentation.

Ok, here is a complete patch with the documentation:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: post-command-select-window.patch --]
[-- Type: text/x-diff, Size: 2742 bytes --]

diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 93b25cbe67f..ecb1df82eba 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -3344,6 +3344,15 @@ Buffer Display Action Alists
 the entries @code{window-height}, @code{window-width} and
 @code{preserve-size} are applied that could resize the window to fit
 it to the inserted contents.
+
+@vindex post-command-select-window@r{, a buffer display action alist entry}
+@item post-command-select-window
+If the value is non-@code{nil}, the buffer displayed by @code{display-buffer}
+is selected after the current command is executed that runs the hook
+@code{post-command-hook} (@pxref{Command Overview}).
+If the value is @code{nil}, the buffer selected by such functions as
+@code{pop-to-buffer} is deselected, and the window that was previously
+selected before calling @code{display-buffer} remains selected.
 @end table
 
 By convention, the entries @code{window-height}, @code{window-width}
diff --git a/lisp/window.el b/lisp/window.el
index 23977691f50..b37502203b1 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7798,6 +7803,13 @@ display-buffer
     and `preserve-size' are applied.  The function is supposed
     to fill the window body with some contents that might depend
     on dimensions of the displayed window.
+ `post-command-select-window' -- A non-nil value means that after the
+    current command is executed and the hook `post-command-hook' is called,
+    the window displayed by this function will be selected.  A nil value
+    means that if functions like `pop-to-buffer' selected another window,
+    at the end of this command that window will be deselected, and the
+    window that was selected before calling this function will remain
+    selected.
 
 The entries `window-height', `window-width', `window-size' and
 `preserve-size' are applied only when the window used for
@@ -7853,6 +7865,17 @@ display-buffer
       (while (and functions (not window))
         (setq window (funcall (car functions) buffer alist)
               functions (cdr functions)))
+      (when-let ((select (assq 'post-command-select-window alist)))
+        (letrec ((old-selected-window (selected-window))
+                 (postfun
+                  (lambda ()
+                    (if (cdr select)
+                        (when (window-live-p window)
+                          (select-window window))
+                      (when (window-live-p old-selected-window)
+                        (select-window old-selected-window)))
+                    (remove-hook 'post-command-hook postfun))))
+          (add-hook 'post-command-hook postfun)))
       (and (windowp window) window))))
 
 (defun display-buffer-other-frame (buffer)

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > However, the name 'select-window' would be too confusing for users
 > because based on such name they will expect that it will select
 > the window immediately after it's displayed.
 >
 > Therefore I propose to rename it to the less ambiguous name
 > 'post-command-select-window'.  Of course it should be documented in
 > any case, but this will help the users who never read the documentation.

That's better.

 > Ok, here is a complete patch with the documentation:

+ `post-command-select-window' -- A non-nil value means that after the
+    current command is executed and the hook `post-command-hook' is called,
+    the window displayed by this function will be selected.  A nil value
+    means that if functions like `pop-to-buffer' selected another window,
+    at the end of this command that window will be deselected, and the
+    window that was selected before calling this function will remain
+    selected.

I'd say "will be usually selected" and "will be usually deselected".
For example, (post-command-select-window . nil) will effectively select
the window that was selected before 'display-buffer' was called,
regardless of which other window were selected after the
'display-buffer'.  Think of

(progn
   (select-window x)
   (pop-to-buffer ... '(post-command-select-window . nil))
   (select-window y))

which will select x overriding the call to select y.  Or think of two
'display-buffer' calls within one and the same command.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

> + `post-command-select-window' -- A non-nil value means that after the
> +    current command is executed and the hook `post-command-hook' is called,
> +    the window displayed by this function will be selected.  A nil value
> +    means that if functions like `pop-to-buffer' selected another window,
> +    at the end of this command that window will be deselected, and the
> +    window that was selected before calling this function will remain
> +    selected.
>
> I'd say "will be usually selected" and "will be usually deselected".
> For example, (post-command-select-window . nil) will effectively select
> the window that was selected before 'display-buffer' was called,

The docstring above says the same:

  "the window that was selected before calling this function
   will remain selected"

> regardless of which other window were selected after the
> 'display-buffer'.

These clarifications could be added to the docstring as well:

  "the window that was selected before calling this function
   will remain selected regardless of which other windows
   were selected later with other calls of 'display-buffer'."

bug#67993: Selecting buffer automatically

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > These clarifications could be added to the docstring as well:
 >
 >    "the window that was selected before calling this function
 >     will remain selected regardless of which other windows
 >     were selected later with other calls of 'display-buffer'."

Maybe

     "the window that was selected before calling this function will
      remain selected regardless of which windows were selected
      afterwards within this command."

would be more precise.

martin

bug#67993: Selecting buffer automatically

[Juri Linkov]

close 67993 30.0.50
thanks

>> These clarifications could be added to the docstring as well:
>>
>>    "the window that was selected before calling this function
>>     will remain selected regardless of which other windows
>>     were selected later with other calls of 'display-buffer'."
>
> Maybe
>
>     "the window that was selected before calling this function will
>      remain selected regardless of which windows were selected
>      afterwards within this command."
>
> would be more precise.

Thanks for reviewing, so now installed with this docstring.