GNU bug report logs - #15555
24.3; Bidirectional display very slow with long lines

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jerome L Quinn <jlquinn <at> us.ibm.com>
Cc: 15555 <at> debbugs.gnu.org
Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Tue, 08 Oct 2013 09:42:53 +0300

> From: Jerome L Quinn <jlquinn <at> us.ibm.com>
> Date: Mon, 7 Oct 2013 16:05:42 -0400
> 
> If I have a buffer with a very long line (14000 chars) with a mix of
> ASCII and Arabic text, emacs gets painfully slow when point is further
> along the line.

Emacs is in general painfully slow with such long lines, even if there
are only ASCII characters there.  Presence of Arabic characters makes
it slower, but it is unbearably slow even before that.  This is a
known deficiency of the Emacs display engine.  This is bug #13675.

> It looks like there's an N^2 algorithm dependent on the column of
> point.

No, there are no N² algorithms.  However, for many display operations,
Emacs needs to go to the beginning of the previous _physical_ line,
and then go forward to the place it needs to redisplay.  With very
long lines, this takes a lot of time.

If your data files don't include empty lines, there's perhaps another
source of slowdown, which _is_ peculiar to bidirectional display:
Emacs needs to find the beginning of the current paragraph to
determine its "base direction".  To see if this is your problem, try
setting bidi-paragraph-direction to either left-to-right or
right-to-left, depending on whether most of the text should be read
left to right or right to left.

> We encounter this kind of data in our work looking at generated
> files.  The only solution at the moment is to disable bidirectional
> reordering.

With 14 thousand characters per line, Emacs is slow even without
reordering.  Again, this is an existing bug.  Disabling reordering is
probably not a very good thing when you work with Arabic text.

> There are also problems with the display.  If you search for the following:
> 
> 74,346,347
> 
> my display looks like:
> 
> ... ,[["74,346,347],".",".","","."], ...
> 
> Whereas it should display:
> 
> ... ,[".","",".",".",[74,346,347]]]], ...
> 
> Note that the first " is misplaced, even if you accept that the rest
> should be reversed.

This is what the Unicode Bidirectional Algorithm mandates, since " is
a "weak" character, i.e. it gets its directionality from the
surrounding text, and because your paragraph has the left-to-right
base direction (because it begins with strong L2R character).  Perhaps
you should set bidi-paragraph-direction to right-to-left, as your text
is predominantly Arabic.

So I see no bug here wrt the display order.  As for slow redisplay
with very long lines, that is an existing bug report.

Previous Next

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