bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50983: 28.0.50; [REGRESSION, BUG] Display bugs with uncommon charact


From: Rudi C
Subject: bug#50983: 28.0.50; [REGRESSION, BUG] Display bugs with uncommon characters
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 <alan@idiocy.org> 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 <alan@idiocy.org>
> > Cc: Rudi C <rudiwillalwaysloveyou@gmail.com>, 50983@debbugs.gnu.org
> >
> > 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]