GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
On 31/01/2023 14:14, Eli Zaretskii wrote:
>> Date: Mon, 30 Jan 2023 23:07:22 +0200
>> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> With the previous change that Gregory had made (different limits for
>> different features, i.e. font-lock uses much wider narrowing bounds
>> which are also customizable) I don't have that much of a horse in that
>> race anymore.
>
> Which change is that? I don't think I follow.
The addition of long-line-locked-narrowing-region-size, I think,
separated the narrowing radius for font-lock from narrowing for the
improvement of other display stuff. I could be wrong there, though.
>> Also note that previously, I'd never have suggested that redisplay code
>> changes the value of font-lock-dont-widen.
>
> Hmm... not sure how is that variable related to this particular
> thread. Please elaborate.
If we drop the locking feature, the display engine could still apply
narrowing around fontification functions (and hooks, and etc). And
perhaps bind font-lock-down-widen to t. Or add a new variable, like
Stefan suggested -- that would be tidier.
That would still not protect us from misbehaving modes, but modes that
absolutely cannot work within a narrowing are a problem anyway.
And for the rest, we have an existing convention (discussed at length
and rubber-stamped by the previous maintainer back then) that major
modes shouldn't call 'widen' in font-lock-keywords. Nor in indentation
code. That was part of the convention which made js-mode, python-mode,
etc, work better with multil-major-mode packages, and it did.
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.