GNU bug report logs - #69093
window-state-put doesn't update current buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69093 in the body.
You can then email your comments to 69093 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: window-state-put doesn't update current buffer
Date: Tue, 13 Feb 2024 09:39:29 +0200

Martin, could you help to understand what is missing in
'window-state-put' that it doesn't set the current buffer
correctly like 'set-window-configuration' does.

For example, here the message says that the current-buffer
and point still have old values coming from the old buffer
that was current before calling 'window-state-put':

(let (ws)
  (info)
  (setq ws (window-state-get nil 'writable))
  (quit-window)
  (window-state-put ws nil 'safe)
  (message "! %S %S %S" (point) (current-buffer) (window-buffer)))

However, 'set-window-configuration' works correctly
and sets the restored buffer as current:

(let (wc)
  (info)
  (setq wc (current-window-configuration))
  (quit-window)
  (set-window-configuration wc nil t)
  (message "! %S %S %S" (point) (current-buffer) (window-buffer)))

Message #8 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Wed, 14 Feb 2024 10:12:04 +0100

> Martin, could you help to understand what is missing in
> 'window-state-put' that it doesn't set the current buffer
> correctly like 'set-window-configuration' does.

The "current buffer" is not part of the state of a window.  It is part
of a more global state.  Have a look at frameset.el which does at some
time "Restore selected frame, buffer and point."

As for what 'set-window-configuration' additionally does, have a look at
'current-window-configuration' where you can see that besides

  XSETBUFFER (data->f_current_buffer, current_buffer);

it also saves the selected frame, scroll and selected windows of that
frame's minibuffer or the frame that should receive input focus.

martin

Message #11 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Thu, 15 Feb 2024 09:29:33 +0200

>> Martin, could you help to understand what is missing in
>> 'window-state-put' that it doesn't set the current buffer
>> correctly like 'set-window-configuration' does.
>
> The "current buffer" is not part of the state of a window.  It is part
> of a more global state.  Have a look at frameset.el which does at some
> time "Restore selected frame, buffer and point."
>
> As for what 'set-window-configuration' additionally does, have a look at
> 'current-window-configuration' where you can see that besides
>
>   XSETBUFFER (data->f_current_buffer, current_buffer);
>
> it also saves the selected frame, scroll and selected windows of that
> frame's minibuffer or the frame that should receive input focus.

Thanks for explanations.  I see this line in 'set-window-configuration':

      Fset_buffer (new_current_buffer);

Do you think this is the right fix?

diff --git a/lisp/window.el b/lisp/window.el
index 6df20353b5e..34e6c5d4a4f 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -6498,7 +6503,8 @@ window-state-put
 	  (when (and (window-valid-p window)
                      (eq (window-deletable-p window) t))
 	    (delete-window window))))
-      (window--check frame))))
+      (window--check frame)
+      (set-buffer (window-buffer)))))
 
 (defun window-state-buffers (state)
   "Return all buffers saved to the given window state STATE."

Message #14 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Fri, 16 Feb 2024 10:39:36 +0100

> Thanks for explanations.  I see this line in 'set-window-configuration':
>
>        Fset_buffer (new_current_buffer);
>
> Do you think this is the right fix?

No.  I think the right fix would be to remove the above line from
'set-window-configuration'.  We can't do that because some applications
might depend on the current behavior.  But I am quite confident that
nobody fully understands 'set-window-configuration' anyway and can
predict what it does when selected frame, current buffer and the buffer
and frame stored in the CONFIGURATION argument mismatch.

Or could you tell beforehand which buffer will be current after

(let ((configuration (current-window-configuration)))
  (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame)))
  (set-window-configuration configuration)
  (current-buffer))

I think that the behavior of

(let ((frame (selected-frame))
      (state (window-state-get)))
  (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame)))
  (window-state-put state (frame-root-window frame))
  (current-buffer))

is much more consistent in this regard.

I'd say that any code run in a state where the buffer of the selected
window and the current buffer are not the same - regardless of whether
this happens when a state/configuration is saved or restored - should
simply report an error.  But that ship has sailed long ago.

martin

Message #17 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Fri, 16 Feb 2024 13:46:24 +0200

> Cc: 69093 <at> debbugs.gnu.org
> Date: Fri, 16 Feb 2024 10:39:36 +0100
> From:  martin rudalics via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
>  > Thanks for explanations.  I see this line in 'set-window-configuration':
>  >
>  >        Fset_buffer (new_current_buffer);
>  >
>  > Do you think this is the right fix?
> 
> No.  I think the right fix would be to remove the above line from
> 'set-window-configuration'.  We can't do that because some applications
> might depend on the current behavior.  But I am quite confident that
> nobody fully understands 'set-window-configuration' anyway and can
> predict what it does when selected frame, current buffer and the buffer
> and frame stored in the CONFIGURATION argument mismatch.

A more worrisome aspect of such a change would be the gazillion uses
of save-window-excursion.

> I'd say that any code run in a state where the buffer of the selected
> window and the current buffer are not the same - regardless of whether
> this happens when a state/configuration is saved or restored - should
> simply report an error.

Some do, others don't.  Still others silently correct the mismatch.

Message #20 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Sun, 18 Feb 2024 09:43:09 +0200

> Or could you tell beforehand which buffer will be current after
>
> (let ((configuration (current-window-configuration)))
>   (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame)))
>   (set-window-configuration configuration)
>   (current-buffer))

Does this ambiguity exist only for multi-frame setups where
a system window manager decides what frame to select afterwards?

Message #23 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Mon, 19 Feb 2024 10:43:00 +0100

>> Or could you tell beforehand which buffer will be current after
>>
>> (let ((configuration (current-window-configuration)))
>>    (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame)))
>>    (set-window-configuration configuration)
>>    (current-buffer))
>
> Does this ambiguity exist only for multi-frame setups where
> a system window manager decides what frame to select afterwards?

The system window manager here does only what Emacs tells it to do.  But
note that multi-frame setups got more and more broken since Emacs 26 and
are maybe not used frequently nowadays.  So you probably needn't give
them much attention in the first place.

martin

Message #26 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Juri Linkov <juri <at> linkov.net>
Cc: "69093 <at> debbugs.gnu.org" <69093 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#69093: window-state-put doesn't update current
 buffer
Date: Mon, 19 Feb 2024 17:36:23 +0000

> note that multi-frame setups got more and more
> broken since Emacs 26

Yes.  Unfortunately the passive voice is needed
here because much has changed without our being
able to identify and say who/what changed what.

> and are maybe not used frequently nowadays.

They _never_ were frequently used.  They were
standard in Epoch, but never integrated into
GNU Emacs OOTB.  GNU Emacs users of them have
always been outliers.  Dunno whether Stefan M
still uses a standalone minibuffer.  If not,
I might be the only user who does.

> So you probably needn't give them much
> attention in the first place.

That's the problem in the first place, and IMO
the reason they've never been used frequently.
Emacs developers don't, themselves, use them,
and so don't test changes against them,...
Vicious circle.  Too bad.

(No, I don't have the time anymore to try to
track down what might have broken what & when.
Just saying that this is unfortunate.  Things
might have been different if GNU Emacs had,
many moon ago, provided a standalone minibuffer
OOTB, a la Epoch.)

Message #29 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Tue, 20 Feb 2024 09:40:11 +0200

>>> Or could you tell beforehand which buffer will be current after
>>>
>>> (let ((configuration (current-window-configuration)))
>>>    (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame)))
>>>    (set-window-configuration configuration)
>>>    (current-buffer))
>>
>> Does this ambiguity exist only for multi-frame setups where
>> a system window manager decides what frame to select afterwards?
>
> The system window manager here does only what Emacs tells it to do.  But
> note that multi-frame setups got more and more broken since Emacs 26 and
> are maybe not used frequently nowadays.  So you probably needn't give
> them much attention in the first place.

Ok, since it's impossible to fix 'window-state-put',
let's narrow the scope just to the single-frame case
in the caller 'tab-bar-select-tab':

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index d653f339fea..efca893fc16 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1477,7 +1489,8 @@ tab-bar-select-tab
           ;; `window-state-put' fails when called in the minibuffer
           (when (window-minibuffer-p)
             (select-window (get-mru-window)))
-          (window-state-put ws nil 'safe)))
+          (window-state-put ws nil 'safe)
+          (set-buffer (window-buffer))))
 
         ;; Select the minibuffer when it was active before switching tabs
         (when (and minibuffer-was-active (active-minibuffer-window))

Message #32 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Wed, 21 Feb 2024 10:04:54 +0100

I'd say that saving a window configuration where the current buffer is
_not_ shown in the selected window is never right.  So can you give me a
practical example where you think that this

> +          (set-buffer (window-buffer))))

is useful or needed?

martin

Message #35 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Wed, 21 Feb 2024 19:27:37 +0200

> I'd say that saving a window configuration where the current buffer is
> _not_ shown in the selected window is never right.  So can you give me a
> practical example where you think that this
>
>> +          (set-buffer (window-buffer))))
>
> is useful or needed?

This fix is needed for this case:

(defun pulse-momentary-highlight-one-line (&optional point face)
  (save-excursion
    (goto-char (or point (point)))
    (let ((start (progn (vertical-motion 0) (point)))
          (end (progn (vertical-motion 1) (point))))
      (pulse-momentary-highlight-region start end face))))

It expects that 'point' should be in the current buffer
that is displayed in the selected window.

But this hook fails:

(add-hook 'tab-bar-tab-post-select-functions
          (lambda (_from-tab _to-tab)
            (pulse-momentary-highlight-one-line)))

because this new hook is called in the patch below
after finishing 'window-state-put' that doesn't
set the current buffer to the window's buffer.
So after 'window-state-put' finishes,
the current buffer stays in some previous buffer.

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 3e1d8278b04..50679f54474 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1499,7 +1565,10 @@ tab-bar-select-tab
               (tab-bar--current-tab-make (nth to-index tabs)))
 
         (unless tab-bar-mode
-          (message "Selected tab '%s'" (alist-get 'name to-tab))))
+          (message "Selected tab '%s'" (alist-get 'name to-tab)))
+
+        (run-hook-with-args 'tab-bar-tab-post-select-functions
+                            from-tab to-tab))
 
       (force-mode-line-update))))
 

Message #38 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Thu, 22 Feb 2024 09:58:12 +0100

> This fix is needed for this case:
>
> (defun pulse-momentary-highlight-one-line (&optional point face)
>    (save-excursion
>      (goto-char (or point (point)))
>      (let ((start (progn (vertical-motion 0) (point)))
>            (end (progn (vertical-motion 1) (point))))
>        (pulse-momentary-highlight-region start end face))))
>
> It expects that 'point' should be in the current buffer
> that is displayed in the selected window.

This function will probably not DTRT when the same buffer is displayed
in two windows with different values of point.  It should use an overlay
with a 'window' property.

> But this hook fails:
>
> (add-hook 'tab-bar-tab-post-select-functions
>            (lambda (_from-tab _to-tab)
>              (pulse-momentary-highlight-one-line)))
>
> because this new hook is called in the patch below
> after finishing 'window-state-put' that doesn't
> set the current buffer to the window's buffer.
> So after 'window-state-put' finishes,
> the current buffer stays in some previous buffer.

If by "fails" you mean that 'window-state-put' does not select the
window selected at the time the corresponding 'window-state-get' was
run, then you should fix this in the tab bar code by recording the
frame's selected window together with the state and, depending on
whether the frame you put the state into is selected or not, either set
that frame's selected window or select that window.  The latter case
should then make that window's buffer current.

If by "fails" you mean that something in ‘window-state-put’ makes the
selected window not show the current buffer, we have to dig further.

But in neither case use 'set-buffer' to fix a window/buffer relationship
that has been screwed up elsewhere.

martin

Message #41 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Thu, 22 Feb 2024 19:23:36 +0200

>> (defun pulse-momentary-highlight-one-line (&optional point face)
>>    (save-excursion
>>      (goto-char (or point (point)))
>>      (let ((start (progn (vertical-motion 0) (point)))
>>            (end (progn (vertical-motion 1) (point))))
>>        (pulse-momentary-highlight-region start end face))))
>>
>> It expects that 'point' should be in the current buffer
>> that is displayed in the selected window.
>
> This function will probably not DTRT when the same buffer is displayed
> in two windows with different values of point.  It should use an overlay
> with a 'window' property.

Agreed, a 'window' property would be nice.

> If by "fails" you mean that 'window-state-put' does not select the
> window selected at the time the corresponding 'window-state-get' was
> run, then you should fix this in the tab bar code by recording the
> frame's selected window together with the state and, depending on
> whether the frame you put the state into is selected or not, either set
> that frame's selected window or select that window.  The latter case
> should then make that window's buffer current.

The window state already has information about the selected window:

  (selected . t)

> If by "fails" you mean that something in ‘window-state-put’ makes the
> selected window not show the current buffer, we have to dig further.

'window-state-put' fails to select the previously selected
window's buffer with the property (selected . t).

Message #44 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Fri, 23 Feb 2024 09:48:05 +0100

>> If by "fails" you mean that something in ‘window-state-put’ makes the
>> selected window not show the current buffer, we have to dig further.
>
> The window state already has information about the selected window:
>
>    (selected . t)

I forgot.  If the selected window is part of the saved state, this is
set.

> 'window-state-put' fails to select the previously selected
> window's buffer with the property (selected . t).

It should have selected it here

		;; Select window if it's the selected one.
		(when (cdr (assq 'selected state))
		  (select-window window))

Please first check whether this 'select-window' call is executed at all
in your scenario.  If it is, please find out which window apparently
gets selected instead afterwards and try to find out why.  If there's no
clue, you would have to find out who undoes that selection first by
putting a breakpoint into Fselect_window and, if that fails, by putting
a breakpoint into select_window (which can be a pain).

martin

Message #47 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Sat, 24 Feb 2024 19:32:56 +0200

>> 'window-state-put' fails to select the previously selected
>> window's buffer with the property (selected . t).
>
> It should have selected it here
>
> 		;; Select window if it's the selected one.
> 		(when (cdr (assq 'selected state))
> 		  (select-window window))
>
> Please first check whether this 'select-window' call is executed at all
> in your scenario.  If it is, please find out which window apparently
> gets selected instead afterwards and try to find out why.

The right window is selected, and its buffer becomes current.

> If there's no clue, you would have to find out who undoes that
> selection first by putting a breakpoint into Fselect_window and, if
> that fails, by putting a breakpoint into select_window (which can be
> a pain).

The problem is that afterwards the same function undoes the setting of
current buffer.  In window--state-put-2, select-window is inside
with-current-buffer that undoes the current buffer selection:

	      (with-current-buffer buffer
                ...
		;; Select window if it's the selected one.
		(when (cdr (assq 'selected state))
                  (select-window window))

Also in window-state-put, with-temp-buffer undoes the current buffer:

      (with-temp-buffer
	(set-window-buffer window (current-buffer))
	(window--state-put-1 state window nil totals pixelwise)
	(window--state-put-2 ignore pixelwise))

Message #50 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Sun, 25 Feb 2024 10:17:24 +0100

[Message part 1 (text/plain, inline)]

> The problem is that afterwards the same function undoes the setting of
> current buffer.  In window--state-put-2, select-window is inside
> with-current-buffer that undoes the current buffer selection:
>
> 	      (with-current-buffer buffer
>                  ...
> 		;; Select window if it's the selected one.
> 		(when (cdr (assq 'selected state))
>                    (select-window window))
>
> Also in window-state-put, with-temp-buffer undoes the current buffer:
>
>        (with-temp-buffer
> 	(set-window-buffer window (current-buffer))
> 	(window--state-put-1 state window nil totals pixelwise)
> 	(window--state-put-2 ignore pixelwise))

Silly me.  So far this apparently never caused any problems because
command_loop_1 makes the buffer of the selected window current.  But it
will affect any code running after calling 'window-state-put' up to and
including the next 'post-command-hook'.

The attached patch (including the former changes) should fix it.  I left
the old 'select-window' call in just for the case that its effect is
used elsewhere in a function called by 'window--state-put-2' later.

Many thanks for the analysis, martin

[keep-windows.diff (text/x-patch, attachment)]

Message #53 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Sun, 25 Feb 2024 20:19:35 +0200

> The attached patch (including the former changes) should fix it.  I left
> the old 'select-window' call in just for the case that its effect is
> used elsewhere in a function called by 'window--state-put-2' later.

Thank you very much.  I confirm that everything works nicely.

Message #56 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Mon, 26 Feb 2024 09:42:28 +0100

> Thank you very much.  I confirm that everything works nicely.

If no problems come up within a week, I'll try to install it.

Thanks for testing, martin

Message #59 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Mon, 4 Mar 2024 10:40:23 +0100

All changes should be on master now.

Thanks for the reviews, martin

Message #62 received at 69093 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 69093 <at> debbugs.gnu.org
Subject: Re: bug#69093: window-state-put doesn't update current buffer
Date: Tue, 05 Mar 2024 19:14:58 +0200

close 69093 30.0.50
thanks

> All changes should be on master now.

Thanks.  I confirm 'window-state-put' working,
so I was able to add 'tab-bar-tab-post-select-functions'.

Previous Next

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