On Wed, Jul 13, 2016 at 08:23:34PM +0200, Sven Joachim wrote: > On 2016-06-22 13:46 +0200, Vincent Lefevre wrote: > > > Control: reassign -1 xterm 325-1 > > This problem seems to stem from the attempt to fix bug #738794, at least > it is not present in xterm 324 and earlier. > > > Control: retitle -1 Character U+2028 can yield file corruption when edited in xterm > > > > This seems to be an xterm bug since there is no such problem in > > urxvt and mlterm, where U+2028 takes its own space. Moreover, I > > get exactly the same problem with vi in xterm. > > > On 2016-06-22 12:48:46 +0200, Vincent Lefevre wrote: > >> When editing a file where a line started by the U+2028 character, > >> it got corrupted. Basically, what was stored is not what was > >> displayed. > > > > To reproduce the beginning of a corruption: > > > > 1. Type: printf "\u2028abcd\n" > file > > 2. Type: "emacs -Q -nw file" or "vi file" > > 3. Move the cursor several times to the right. > > > > One gets successively: > > > > abcd (no cursor) > > aacd (cursor on the 2nd column) > > aabd (cursor on the 3rd column) > > aabc (cursor on the 4th column) > > aabcd (cursor on the 5th column) > > That's not quite what I get, but the output is certainly corrupted. > Basically what I see is in Emacs (moving from column 0 to 5): > cd → ad → ab → abc → abcd → abcd. I don't see the behavior which is described, and haven't seen any suitable justification for marking this as a "grave" issue, rather than "normal". Keep in mind that this is a rarely used line-break character. What I see on the screen is a box-outline for the nonprintable character (no space). -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net
Attachment:
signature.asc
Description: Digital signature