[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69611: 30.0.50; Long bidi line with control characters freezes Emacs
From: |
Stephen Berman |
Subject: |
bug#69611: 30.0.50; Long bidi line with control characters freezes Emacs |
Date: |
Thu, 07 Mar 2024 22:21:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On Thu, 07 Mar 2024 21:19:31 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.
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