Bug#655589: screen: corrupt display due to the U+200F character (RIGHT-TO-LEFT MARK) or similar

[Vincent Lefevre]

On 2022-05-26 01:07:19 +0200, Vincent Lefevre wrote:
> If I replace \u061c by \u200f above, I cannot reproduce the issue.
> U+200F is in the "combining" table, but it was already there in 2009.

In the Debian package, if I add "{ 0x061C, 0x061C }," to
the "combining" table in encoding.c, this makes the issue
with this character disappear. But I don't know whether
this is the right fix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#655589: screen: corrupt display due to the U+200F character (RIGHT-TO-LEFT MARK) or similar

[Vincent Lefevre]

On 2022-05-26 00:19:30 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > In a 80-column xterm, execute "screen bash", then
> > 
> >   for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo
> 
> That's not U+200F (RIGHT-TO-LEFT MARK) which you put in the subject
> but U+061C ARABIC LETTER MARK. Updating the bug title accordingly.

Indeed. The U+200F text came from the original bug report.

If I replace \u061c by \u200f above, I cannot reproduce the issue.
U+200F is in the "combining" table, but it was already there in 2009.
Perhaps it is more complex to see if the bug can still be reproduced
with this character (I should try again with the character unfiltered
in Mutt).

[...]
> The glyph shown to me looks like an "a" with an "u" diacritical and on
> top of that three vertical dots. (Tried to replace it above with "a̍̎"
> which seems to come optically closest to the glyph I've been seeing.)

I don't think that this is some kind of diacritical. In my case,
it looks like an "a" and a dotted square in the same cell, perhaps
because the wcwidth of U+061C is 0.

[...]
> But even when I copy and paste it from the Screen session into a
> text-mode Emacs (also inside a Screen session, but a different one),
> it is shown me as "a؜؜" (looks like "a__" in Emacs to me), but is
> actually still an "a" with 2x U+61C, ARABIC LETTER MARK behind it and
> while moving through that string with Ctrl-F the cursor jumps (IMHO
> correctly) once two positions forward, then one backward and again two
> positions forward.

That may be because arabic is a right-to-left script, so the two
U+061C characters appear right-to-left.

> P.S.: I've updated the upstream link from HTTP to HTTPS, i.e. I didn't
> change which upstream bug is referenced, just the link's protocol.

Thanks.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#655589: screen: corrupt display due to the U+200F character (RIGHT-TO-LEFT MARK) or similar

[Axel Beckert]

Control: forwarded -1 https://savannah.gnu.org/bugs/?43145
Control: retitle -1 screen: corrupt display due to the U+061C character (ARABIC 
LETTER MARK) or similar

Hi,

Thanks for these additional details and especially the easy
reproducer!

Vincent Lefevre wrote:
> The issue can be reproduced in the following way without needing Mutt:
> 
> In a 80-column xterm, execute "screen bash", then
> 
>   for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo

That's not U+200F (RIGHT-TO-LEFT MARK) which you put in the subject
but U+061C ARABIC LETTER MARK. Updating the bug title accordingly.

> then reduce the terminal window by one line. This has the effect
> to duplicate the prompt and move the status line 2 lines above.

Indeed, can confirm.

Actually for me it already moves the status bar up one line without
resizing the terminal window — actually duplicating it except for the
time in the "upper" status bar which is no more updated.

The terminal window looks like this for me:

abe@c6:~ $ for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo
a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆
abe@c6:~ $
   _

where the a̍̎̆ above comes closest to the glyph shown to me by the uxterm
in which I started the screen session.

The glyph shown to me looks like an "a" with an "u" diacritical and on
top of that three vertical dots. (Tried to replace it above with "a̍̎"
which seems to come optically closest to the glyph I've been seeing.)

And that last underscore shows the position of the cursor shown to me.
I.e. the correct column, but one line lower than it should.

But even when I copy and paste it from the Screen session into a
text-mode Emacs (also inside a Screen session, but a different one),
it is shown me as "a؜؜" (looks like "a__" in Emacs to me), but is
actually still an "a" with 2x U+61C, ARABIC LETTER MARK behind it and
while moving through that string with Ctrl-F the cursor jumps (IMHO
correctly) once two positions forward, then one backward and again two
positions forward.

And the status line(s) looks like this:

c6: 0 bash | 0* bash | 2.34 2.83 3.13 | 23:41:41
c6: 0 bash | 0* bash | 4.55 3.25 3.05 | 23:52:32

I've configured this status line:

hardstatus alwayslastline "%H: %n %t | %w | %l | %c:%s"

And it seems even worse if you have (had) split windows inside the
screen session, i.e. by doing "C-a S" before executing the above
command: the layout is gone afterwards (except for some displayed
leftovers of the delimiter line) and only one is left window left —
the one in which I called that command.

P.S.: I've updated the upstream link from HTTP to HTTPS, i.e. I didn't
change which upstream bug is referenced, just the link's protocol.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#655589: screen: corrupt display due to the U+200F character (RIGHT-TO-LEFT MARK) or similar

[Vincent Lefevre]

Control: retitle -1 screen: corrupt display due to the U+200F character 
(RIGHT-TO-LEFT MARK) or similar
Control: found -1 4.9.0-1

On 2013-05-08 22:36:31 +0200, Vincent Lefevre wrote:
> This problem still occurs. I've seen it again on a spam. This
> introduced a shift in the message index display of my mailbox,
> so that when I wanted to delete a mail, it was the next one that
> was actually selected for deletion! This means that I could have
> lost mail if I didn't look at this more closely!
> 
> I've built a second testcase (attached) based on this:
> 
> 1. Open a 80x7 terminal (e.g. xterm).
> 2. screen mutt -F mscreen2b.muttrc -f mscreen2b
> 3. Type  (next-page).
> 4. Type ^L (refresh).
[...]

There has been a workaround in Mutt, so that this should no longer
occur in Mutt (but possibly in other curses applications).

Yesterday I received another spam yielding the same kind of issue,
this one with U+061C ARABIC LETTER MARK characters:

  https://gitlab.com/muttmua/mutt/-/issues/413

The issue can be reproduced in the following way without needing Mutt:

In a 80-column xterm, execute "screen bash", then

  for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo

then reduce the terminal window by one line. This has the effect
to duplicate the prompt and move the status line 2 lines above.

I've attached 2 screenshots:
  * screen-061c-1.png (just before the resize)
  * screen-061c-2.png (just after the resize)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)