emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: run_window_configuration_change_hook


From: martin rudalics
Subject: Re: run_window_configuration_change_hook
Date: Tue, 19 Apr 2011 14:43:10 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]