GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
>
> So we are removing all the stuff that prevented font-lock from slowing
> down redisplay when long lines are in the buffer? IOW, something which
> we have for several months, and which so far brought up only one
> complaint? Frankly, this makes no sense to me, unless we delay the
> pretest for another half year or so. It's too late for such changes.
>
> Or am I missing something?
>
I looked with a critical eye at the code I wrote, and concluded that the
cure is worse than the disease.
It's true that some slowdowns caused by font-locking are prevented by
locked narrowing, but:
1. The slowdowns caused by font-locking were not the major cause of
slowdowns in buffers with long lines. They were the "last step" to make
editing operations in such buffers as fast as possible, and my opinion now
is that that last step was a step too far. Efficiency issues in font
locking routines are the responsibility of mode authors. Efficiency
issues in the redisplay routines are the responsibility of Emacs, and have
been dealt with.
2. Locked narrowing does not prevent all slowdowns caused by font-locking.
3. Locked narrowing can create slowdowns (e.g. infinite loops) that do not
exist when it is not present.
4. Mode authors who do care about efficiency will update their modes to
deal with problematic buffers, and do not need to be incited by locked
narrowing to do so.
5. Mode authors who do not care about such problematic buffers will simply
replace calls to "(widen)" by "(narrowing-unlock 'fontification-functions)
(widen)" in their code, and the situation will not have improved.
This bug report was last modified 2 years and 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.