Subject: Re: bug#69611: 30.0.50; Long bidi line with control characters freezes Emacs
From: Stephen Berman <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked]
Date: Thu, 07 Mar 2024 22:21:54 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

On Thu, 07 Mar 2024 21:19:31 +0200 Eli Zaretskii <[email-masked]> wrote:

>> From: Stephen Berman <[email-masked]>
>> Cc: [email-masked]
>> 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.

It would be interesting to test this; perhaps I can without too much
effort add the missing controls to make them balanced.  I'll take a look.

>> > 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.

Ah, ok, then that explains it.

>> > 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.

Yeah, that would be going overboard.  I'm more than satisfied with the
explanations you've provided, so I'm going ahead and closing this bug.
Thanks again.

Steve Berman