GNU bug report logs - #17678
24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: esq <at> lawlist.com, 17678 <at> debbugs.gnu.org
Subject: bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before	visual redisplay
Date: Fri, 13 Jun 2014 17:47:59 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: esq <at> lawlist.com,  17678 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2014 10:14:03 -0400
> 
> > Not necessarily: there are the w->optional_new_start and
> > w-> force_start flags, which determine what redisplay does with
> > window-start in these cases.
> > Also, the window-start could be set to a value that leaves point out
> > of the displayed area, in which case it won't be in effect.
> 
> Right, but these fall back into the case where redisplay performs
> a second pass trough the window/buffer, so it's similar to the scrolling
> case, right?

Not necessarily, AFAIR.  Sometimes these situations are detected and
handled on the fly.

> >> If OTOH redisplay decides to scroll, it won't re-execute
> >> pre-redisplay-function, so Elisp doesn't get a chance to react to this
> >> new window-start.
> > ??? Then what are those calls to run_window_scroll_functions that
> > redisplay issues?
> 
> Ah, right, I forgot about this.  So maybe window-scroll-functions is the
> answer to the OP's needs!

Or maybe we should call them in more places during redisplay.

Previous Next

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