GNU bug report logs - #13248
24.2.50; select-window moves point (in comint-postoutput-scroll-to-bottom)

Previous Next

Full log

View this message in rfc822 format

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13248 <at> debbugs.gnu.org
Subject: bug#13248: 24.2.50; select-window moves point (in comint-postoutput-scroll-to-bottom)
Date: Fri, 21 Dec 2012 15:38:55 +0100

  >> martin rudalics <rudalics <at> gmx.at>
  >> on Fri, 21 Dec 2012 15:25:07 +0100 wrote:

  >> Here is what I found during my investigation.  It happens with
  >> (select-window w) in the `comint-postoutput-scroll-to-bottom'
  >> (reproduced below). I was monitoring the value of the (point) just
  >> before and after it, and it looks like this:
  >> 
  >> before (point):9943
  >> after  (point):8619
  >> 
  >> So the point is clearly moved in select-window. Moreover the (point)
  >> equals (window-end) just before select-window is called, so it is
  >> visible. Consequently, the following (comint-adjust-point selected) is
  >> completely screwed because it relies on point *not* being moved!
  >> 

  > select_window (in window.c) has the following comment

  >   /* 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.  */

  > Is it this behavior that bothers you?

Yes, indeed this is precisely what happening. Thanks, it clarifies the
problem.

  > IIUC what you want in `comint-postoutput-scroll-to-bottom' is to
  > `set-window-point' of the respective window.  If you really want to move
  > `point' in a buffer _and_ show the effect in a window, do it with that
  > window selected.

And this is what comint-postoutput-scroll-to-bottom fails to do.

    Vitalie

Previous Next

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