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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 07 Aug 2022 00:29:05 +0000
[Message part 1 (text/plain, inline)]
>
> The problems with C-n/C-p were unrelated, and seem to be a very old bug. 
> I've now mostly fixed that on master (and hopefully didn't introduce any 
> regressions while at that).
>

Thanks!  Indeed these problem seem fixed now, it's much better.  I did not 
see any regressions, if I see anything I'll tell you.  One case that still 
isn't quite right apparently is the arabic-small.txt.json file.  If I open 
that file with emacs -Q and type C-f, or C-n, or C-p, point moves to EOB 
(but strangly, not in 100% cases), and there C-a, or M-<, or C-p, or C-n 
do not seem to work anymore.

>
> In general, layout calculations when we have very long stretches of R2L 
> text in a left-to-right paragraph are very tricky, because many 
> assumptions become false.
>

Frankly, would programming be as fun as it is if assumptions were true? 😉

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.