Subject: Re: bug#50983: 28.0.50; [REGRESSION, BUG] Display bugs with uncommon characters

From: Rudi C <[email-masked]>
Date: Sun, 3 Oct 2021 14:30:56 +0330

> I don't see these problems in normal ascii text, or even normal UTF-8 text

Are the text files I have attached not normal UTf-8? (I have no idea how to
notice if they are normal or not.)

> support for bidirectional text

This is irrelevant to these bugs, I think. If your terminal does RTL
reordering, then emacs does that, too, so the ordering will get reversed,
but it shouldn't have anything to do with these two bugs.

Also, can you be more specific about where you do observe the bugs? In TUI
emacs on iTerm?

I can confirm that the bug with `weird.txt` happens on iTerm, too, again
with both emacs and neovim! But the bug with `bug.txt` does not happen in
iTerm, only on Kitty.

On Sun, Oct 3, 2021 at 1:55 PM Alan Third <[email-masked]> wrote:

> On Sun, Oct 03, 2021 at 01:04:36PM +0300, Eli Zaretskii wrote:
> > > Date: Sun, 3 Oct 2021 10:54:01 +0100
> > > From: Alan Third <[email-masked]>
> > > Cc: Rudi C <[email-masked]>, [email-masked]
> > >
> > > For the record I can't see these problems on GUI emacs
> > > on the mac, but I do see them in the terminal using iTerm2.
> >
> > Does iTerm2 have some support for bidirectional text?  If so, you need
> > to disable it for Emacs -nw to display bidirectional text correctly.
>
> I don't see any options (but there are a LOT of options).
>
> > > It looks like sometimes the display is incorrect, and other times the
> > > action actually changes the underlying buffer contents in an
> > > unexpected way.
> >
> > Any idea what could cause that?  Does it happen with plain-ASCII text
> > as well?
>
> Actually, I was wrong. If I follow the instructions for the first
> example, by removing the character indicated by an underscore in
> Rudi's first screenshot, it actually deletes the previous "o" in
> "note", and displays the rest wrongly, as shown in his second
> screenshot.
>
> If I put the cursor over that underscore character and do
> describe-char, it tells me it's an "o", so the problem exists even
> before editing.
>
> I don't see these problems in normal ascii text, or even normal UTF-8
> text, even RTL. For example the Hebrew text in HELLO behaves exactly
> as I'd expect.
> --
> Alan Third
>