GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 16526 <at> debbugs.gnu.org
Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Sat, 25 Jan 2014 18:30:17 +0200

> Date: Sat, 25 Jan 2014 15:58:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16526 <at> debbugs.gnu.org, acm <at> 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.

Previous Next

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