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 <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
