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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, stephen.berman <at> gmx.net,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 10 Aug 2022 22:13:28 +0300

> Date: Wed, 10 Aug 2022 21:54:04 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, stephen.berman <at> gmx.net,
>  monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > No, because font-lock is much more important than the effect of the
> > BPA.  (Do you even understand what the BPA does, and did you ever see
> > it in action?  Without that, this part of the discussion is just waste
> > of time.)
> 
> I have looked at examples now. Seems important for text in pertinent 
> human languages.

Yes.  Which JSON isn't.  But most PL modes have comments and strings,
and that's where this is important.

> >> We could add (setq bidi-inhibit-bpa nil) to prog-mode, I suppose.
> > 
> > Not to prog-mode, that I won't agree.  But maybe for JSON files, if we
> > think they are unlikely to suffer.
> 
> Sure, maybe.
> 
> Where do we draw the line, though? Not in prog-mode because a .js file, 
> say, can have comments in Persian or Hebrew?
>
> By that measurement, JSON is fine (no comments supported). But JSON 
> contains a bunch of strings, could store localizations, etc.

I presume that JSON files are rarely for human consumption, so the
strings are not very important.  And they will rarely include R2L
characters to begin with.

> I suppose the contents of said strings can store i18n text, with the 
> expectation of a user being able to edit it.

If and when that happens, users can turn BPA back on.

> > There are no caches for a good reason: the Unicode Bidirectional
> > Algorithm that we implement results in very far-reaching non-local
> > effects of small changes.  Even inserting or deleting a single
> > character can dramatically change how the buffer looks on display very
> > far from the locus of the change.
> 
> In both directions?

Yes (IIUC what you mean by that).  The effect back happens rarer than
forward, but it does happen.

Previous Next

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