bug#69611: 30.0.50; Long bidi line with control characters freezes Emacs

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69611@debbugs.gnu.org
> Date: Thu, 07 Mar 2024 18:52:20 +0100
> 
> In the case of the file I sent you, I may be to blame for the unbalanced
> control characters: after yanking the Arabic into Emacs, I did some
> editing of it and may well have unintentionally deleted some of the
> control characters.  At the time I wasn't even aware of these; only
> after (re)reading the section on bidirectional display in the Elisp
> manual did I enable glyphless-display-mode and saw the characters, but I
> didn't bother to check if they paired up properly.

In that case, it could be that the original file wouldn't be so
expensive, if each short Arabic string was included in a right-to-left
embedding, i.e. RLE before it and PDF after it.  Then we wouldn't have
nested embeddings, and each embedding would be quite short.  This
should produce quite "normal" display speed, not different from when
displaying bidirectional text without the control characters at all.
IOW, it could be that by deleting some of the controls you created the
nested embeddings that were not there in the first place.

> > The extremely deep nesting of embeddings in the file, coupled with the
> > fact that the first embedding starts near the beginning of the file,
> > but ends very near its end, causes the algorithm that finds where to
> > position the cursor to fail, because it cannot cope with the situation
> > where, after C-f or C-b, the position of point is very far outside of
> > the window.  I guess this causes some infloop (even though I don't see
> > it here, I just see that the cursor doesn't move although point does
> > move).  It could also be just a very long calculation, not an infloop,
> > because finding where to place the window-start point in this case is
> > also very expensive.
> 
> Ok.  But this is only an issue in conjunction with long lines, right?

Yes, because all the embedding levels are reset at the newline.  So
having a newline not far away guarantees that the reordering code
doesn't need to look too far for where the embedding ends.

> > This file is an interesting curiosity, as far as I'm concerned, but I
> > doubt whether I will find enough time and motivation to try to speed
> > up Emacs when such crazy files are visited.
> 
> Given the special circumstances of this file's creation I think there's
> no need to spend any more time it, so unless you decide you do want to,
> as far as I'm concerned this bug can be closed.  It might be beneficial
> to others to document the issue briefly, either in the Elisp manual
> under Bidirectional Display or just in etc/PROBLEMS, but maybe this is
> such an unusual case that even that isn't worth the effort.

I doubt it's worth describing, since even explaining what happens
needs a long treatise on what are bidirectional embedding levels, how
they affect reordering, and how Emacs implements that reordering in a
way that fits into the general structure of the Emacs display code
(which examines characters in their visual order).  We'd basically
need to copy into PROBLEMS or the manual large portions of the
commentary at the beginning of bidi.c, which includes a lot of
technical details.