bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Eli Zaretskii]

> Date: Sat, 25 Jan 2014 15:58:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16526@debbugs.gnu.org, acm@muc.de
> 
>  > Probably.  I actually don't understand how come scroll-conservatively
>  > affects non-scrolling commands.  Can you elaborate on that?
> 
> How should I know?  I suppose redisplay_window eventually winds up
> calling the fontification function and sooner or later the c-code calls
> back_comment.

Yes, that's what happens.  And it cannot be avoided, AFAICS, when
scroll-conservatively is on.

>  > You also mentioned back_comment doing something unreasonable.  Can you
>  > expand on that, too?  This part specifically I don't understand:
>  >
>  >> What happens is that apparently back_comment 530 times scans the buffer
>  >> from the beginning of the buffer to the first comment before the current
>  >> position where the list of current positions goes like this:
>  >
>  > Since the problem happens as result of beginning-of-buffer, why would
>  > back_comment need to "scan the buffer from the beginning of the buffer
>  > to the first comment before the current position"?  And what is the
>  > current position in this case?
> 
> I earlier posted the first and last positions here:
> 
> (780 14143 15852 18026 20032 20480 21464 21846 22845 23484 25453 26968
> ...
> 942907 943099 944334 948653 948830 948653 948830 948653 948830 948653
> 948830 780 12)

What I see is that find_defun_start is called many times, with its
first argument moving from _end_ of the buffer backwards.  This
happens when Emacs needs to redisplay the last portion of the buffer,
immediately after the call to end-of-buffer.

Alan, I suspect that you tried to reproduce this without setting
scroll-conservatively to a value above 100.  Because otherwise this is
100% reproducible.

If you still cannot reproduce this, please tell us what information to
collect for you.

>  > Btw, if I disable font-lock ("M-x global-font-lock-mode RET") before
>  > repeating the recipe, the move to bob is instantaneous, and turning on
>  > font-lock after that doesn't seem to have any adverse effects on
>  > responsiveness.
> 
> Sure.  The problem happens obviously via jit-lock.

JIT Lock is triggered also when font-lock is turned on after the move
to end of the buffer.  But the difference seems to come from the fact
that under scroll-conservatively, we examine the buffer a little bit
above/below the window, when we decide where to put window-start.