run_window_configuration_change_hook

run_window_configuration_change_hook

[martin rudalics]

With current trunk and emacs -Q evaluate the following code:

(let* ((old-window (selected-window))
        (new-frame (make-frame))
        (new-window (frame-root-window new-frame)))
   (set-window-buffer new-window (other-buffer))
   (select-window old-window)
   (let ((current-buffer (window-buffer new-window)))
     (split-window new-window)
     (cons current-buffer (current-buffer))))

 From the return value I can deduce that `split-window' changes the
current buffer.  This would be incorrect.  IIUC the behavior is due to
the fact that run_window_configuration_change_hook

   if (SELECTED_FRAME () != f)
     {
       record_unwind_protect (select_frame_norecord, Fselected_frame ());
       select_frame_norecord (frame);
     }

   /* Use the right buffer.  Matters when running the local hooks.  */
   if (current_buffer != XBUFFER (Fwindow_buffer (Qnil)))
     {
       record_unwind_protect (Fset_buffer, Fcurrent_buffer ());
       Fset_buffer (Fwindow_buffer (Qnil));
     }

   ...

   unbind_to (count, Qnil);

first restores the current buffer and afterwards the selected frame
which can make another buffer current.  Inverting the order of the two
clauses resolves the problem for me.

martin

Re: run_window_configuration_change_hook

[martin rudalics]

Please disregard this post.  My scenario was wrong.

martin

Re: run_window_configuration_change_hook

[martin rudalics]

A hopefully correct scenario for reproducing the bug goes as follows:
With the current trunk do emacs -Q and evaluate the following form:

(let ((frame (selected-frame))
       (window (frame-root-window (make-frame))))
   (set-window-buffer window "*Messages*")
   (split-window window)
   (select-frame frame)
   (with-current-buffer "*Messages*"
     (adjust-window-trailing-edge window 1 nil)
     (message "%s" (current-buffer))))

The call to `adjust-window-trailing-edge' changes the current buffer
from *Messages* to *scratch* here.

As stated before the reason is that run_window_configuration_change_hook
has this code

   if (SELECTED_FRAME () != f)
     {
       record_unwind_protect (select_frame_norecord, Fselected_frame ());
       Fselect_frame (frame, Qt);
     }

   /* Use the right buffer.  Matters when running the local hooks.  */
   if (current_buffer != XBUFFER (Fwindow_buffer (Qnil)))
     {
       record_unwind_protect (Fset_buffer, Fcurrent_buffer ());
       Fset_buffer (Fwindow_buffer (Qnil));
     }

which implies to first restore the current buffer and afterwards the
selected frame which can make another buffer current.  Inverting the
order of the two clauses resolves the problem for me.  Since I hardly
ever use more than one frame, I'm not 100% sure whether reverting the
clauses can break existing code.  Comments welcome.

martin

Note: The bug cannot be reproduced by using `split-window' alone as I
tried earlier since that wraps run_window_configuration_change_hook in
set_window_buffer which takes some care to restore the current buffer.

Re: run_window_configuration_change_hook

[Stefan Monnier]

> As stated before the reason is that run_window_configuration_change_hook
> has this code

>   if (SELECTED_FRAME () != f)
>     {
>       record_unwind_protect (select_frame_norecord, Fselected_frame ());
>       Fselect_frame (frame, Qt);
>     }

>   /* Use the right buffer.  Matters when running the local hooks.  */
>   if (current_buffer != XBUFFER (Fwindow_buffer (Qnil)))
>     {
>       record_unwind_protect (Fset_buffer, Fcurrent_buffer ());
>       Fset_buffer (Fwindow_buffer (Qnil));
>     }

> which implies to first restore the current buffer and afterwards the
> selected frame which can make another buffer current.

Indeed, that sounds wrong.

> Inverting the order of the two clauses resolves the problem for me.
> Since I hardly ever use more than one frame, I'm not 100% sure whether
> reverting the clauses can break existing code.  Comments welcome.

I think swapping the two is the right thing to do, yes.


        Stefan