GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 13 Aug 2022 14:24:17 +0000

> 
> But they're not. Of course, modes might have problematic rules 
> (font-lock-keywords are turing-complete, after all), but it might be 
> just as easy to fix all the main major modes rather than hobble user 
> experience.
>

You've made it quite clear that in your opinion incorrect font locking 
hobbles user experience more than multi-second delays between motion or 
search commands.  Let's agree to disagree.

>
> Especially if we limit ourselves to modes that are likely to be used 
> with large files.
>

That's not the intention, no.

>
> So please go ahead and experiment, and report on your findings later.
>

I already did, and told you that these multi-second delays were still 
present in larger JSON files (and therefore also in smaller files with 
slower CPUs).

>
> Then the goal failed because we don't disable bidi hpa? It has a much 
> more noticeable effect on editing that font-lock.
>

That's not correct, no.  The BPA algorithm makes C-n and C-p slower at the 
beginning of large files only in a very specific case: when the beginning 
of the buffer contains opening brackets whose matching closing bracket is 
at the end of the buffer.  And the BPA algorithm does not cause 
multi-second delays.

>
> And of course if we wanted to make everything as smooth as possible on 
> every possible machine down to TI calculators,
>

That's not what I aim at, and I think you understood that.

>> Which is why fixing js-mode, and adding a json-mode, as you did, is a 
>> "too local" fix. Of course, that doesn't mean what you did is useless; 
>> it only means that it cannot be considered as a general solution to the 
>> problem at hand.
> 
> That's not what the branch contains.
>

You're playing with words.  The fixes to js-mode and the added json-mode 
are not on the branch because you installed them on master, but what you 
claim the branch demonstrates depends on what you installed on master. 
Or do you claim that what the branch contains makes editing any other file 
(that is, not a .js or a .json file) almost as fast as what is on master?

Previous Next

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