GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #535 received at 56682 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> No, it happens when the buffer is opened. Given the importance that
>> you and Stefan seem to give to that function, it is, with the patch I
>> sent in my previous post, called once on the whole buffer (without any
>> narrowing) when the file is opened.
>
> But if the buffer is not scrolled to the end, shouldn't it be called
> with a position that's close to the beginning?
>
> That shouldn't force the full buffer scan, meaning this call should
> complete quickly.
>
I'm trying to reconcile two conflicting constraints.
It is necessary to add a locked narrowing around fontification-functions
and pre/post-command-hook to ensure that Emacs remains responsive.
At the same time, you and Stefan tell me that syntax-ppss does an
important job and will not do it correctly with such a locked narrowing,
IOW, that at least syntax-ppss should be called without a locked
narrowing. But you also tell me that its result is cached so that a full
buffer scan isn't necessary anymore when it has happened at least once.
So what I'm suggesting is to do a full buffer scan immediately, when the
file is opened, without any narrowing. If that happens, later calls to
syntax-ppss inside fontification-functions and pre/post-command-hook will
use the cached result of the initial scan, and will do their job correctly
even with a locked narrowing.
Unless I misunderstand something, I think (and my tests seem to confirm)
that that would be a workable solution, provided that the initial scan is
reasonably fast, that is, at least six times faster than it is now.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.