GNU bug report logs - #14508
scroll-conservatively==1 not honored for fast line by line navigation up

Previous Next

Full log

Message #14 received at 14508 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 14508 <at> debbugs.gnu.org
Subject: Re: bug#14508: scroll-conservatively==1 not honored for fast line by
	line	navigation up
Date: Fri, 07 Jun 2013 22:27:51 +0300

> Date: Fri, 7 Jun 2013 12:37:08 -0400
> From: Barry OReilly <gundaetiapo <at> gmail.com>
> Cc: 14508 <at> debbugs.gnu.org
> 
> In the same C++ buffer as before, when I hold to repeat the above
> command that scrolls up*, the display doesn't update at all until I
> release the key to stop the repeat. As you indicated it may, the
> scroll down can keep up in this case. I turned font locking off and
> the scroll up redisplay keeps up. I also tried this in a Python buffer
> with font lock on and these commands keep up much better. Is it that
> the C/C++ font locking is more complex?

Could be, I wouldn't know (and don't use Python enough to share my
experience).

> Has C/C++ major mode been
> performance tuned for this use case? Maybe I can experiment with my
> local configuration to temporarily disable font locking while I'm
> scrolling up fast -- seeing non font locked code fly by would be
> better than nothing at all.

I'd suggest to try activating jit-lock-stealth and/or jit-lock-defer
instead.  These two features should make the problem less acute, once
you tune the customization parameters, jit-lock-stealth-time and
jit-lock-defer-time, correspondingly.

Previous Next

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