GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1114 received at 56682 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 05 Aug 2022 11:50:56 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> dgutov <at> yandex.ru
>
> > There's (at least) one more aspect of this, as long as Text mode is
> > being used: Text mode doesn't force bidi-paragraph-direction to be
> > left-to-right, whereas all descendants of prog-mode, including js-mode,
> > do. Leaving bidi-paragraph-direction at nil means Emacs needs to
> > determine the base paragraph direction each time it's about to redisplay
> > a window, and that might be expensive, especially in a large buffer
> > without any paragraph breaks (by default, an empty line), because that
> > is determined by the first strong directional character of the
> > paragraph. So for a more fair comparison with Text mode, you should set
> > bidi-paragraph-direction to the value left-to-right in text-mode
> > buffers.
>
> Indeed, that seems to be the culprit here, I didn't know that text-mode
> was an exception here. If I set bidi-paragraph-direction to
> 'left-to-right after visiting the arabic-small.txt file, Emacs (mis)
> behaves like it does for the other Arabic files: it becomes slow, and C-n
> C-p do not work correctly anymore.
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).
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.
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.