emacs-devel
[Top][All Lists]
Advanced

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

Re: Window configurations


From: martin rudalics
Subject: Re: Window configurations
Date: Tue, 08 Jun 2010 15:06:48 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

> I know.  Maybe we should "fix it", as you implicitly suggested, by
> simply always doing a set-buffer.  It's fairly risky, kind of like
> replacing every (save-excursion (set-buffer foo) bar) with
> (with-current-buffer foo bar) ;-)

I haven't looked into the calls in xdisp.c but I hope you're right ;-)

Vivisecting Fselect_window reveals at least three suspicious components.
------------------------------------------------------------------------
  /* Store the current buffer's actual point into the
     old selected window.  It belongs to that window,
     and when the window is not selected, must be in the window.  */
  if (!NILP (selected_window))
    {
      ow = XWINDOW (selected_window);
      if (! NILP (ow->buffer))
        set_marker_both (ow->pointm, ow->buffer,
                         BUF_PT (XBUFFER (ow->buffer)),
                         BUF_PT_BYTE (XBUFFER (ow->buffer)));
    }

I suppose "current buffer" means the buffer displayed in the currently
selected window which is not the window we are going to select.  Why the
heck do we care about storing `point' into that window's `window-point'?
------------------------------------------------------------------------
  XBUFFER (w->buffer)->last_selected_window = window;

IMHO it's a bug to not set last_selected_window when the selected window
did not change but the buffer displayed in it did change.  It means that
when we remove the buffer from the window and display it in that window
again Emacs will not go to the previous `window-point' but to `point'.
------------------------------------------------------------------------
  /* Go to the point recorded in the window.
     This is important when the buffer is in more
     than one window.  It also matters when
     redisplay_window has altered point after scrolling,
     because it makes the change only in the window.  */
  {
    register int new_point = marker_position (w->pointm);
    if (new_point < BEGV)
      SET_PT (BEGV);
    else if (new_point > ZV)
      SET_PT (ZV);
    else
      SET_PT (new_point);
  }

It sets `point' to `window-point'.  If the selected window didn't change
but the buffer did, the buffer's `point' is not changed.  Obviously,
command_loop_1 will fix this eventually but any code running after the
call of `select-window' will have `point' positioned as whether the
selected window changed or not.
------------------------------------------------------------------------
Neither of these seems to have bothered anyone so far.  But the problem
Juri brought up wasn't noticed either - till now.

martin



reply via email to

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