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

[Alan Third]

On Sun, Oct 03, 2021 at 01:49:29PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 3 Oct 2021 11:24:59 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: rudiwillalwaysloveyou@gmail.com, 50983@debbugs.gnu.org
> > 
> > > > 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.
> 
> Is this in a GUI frame or a TTY frame?

All TTY, GUI works fine.

> And what do you mean by "underscore character"? What is its Unicode
> codepoint?

In the screenshot (and in my own iTerm2 session) there is an
underscore character after "note-". I think it's inserted by the
terminal as a placeholder for something it doesn't understand.

In GUI Emacs that position in the file has a zero width character.

If I do describe-char on the underscore it says it's a plain ascii
"o", which is clearly incorrect. In GUI it says it's 8203 (0x200B),
"ZERO WIDTH SPACE", and as I said it displays as a zero width space.

I think I agree with your other email that it's down to the terminal
doing something strange with characters it doesn't understand.
-- 
Alan Third