Hi,
On 2016-12-01 02:00:59 +0100, Axel Beckert wrote:
> JFTR: IMHO this issue has not "a major effect on the usability of
> the package" (c.f. https://www.debian.org/Bugs/Developer#severities),
> but since I'm rather sick of playing severity ping-pong, I'll leave it
> as is, at least for now.
By silently giving wrong information to the user, it can cause
data loss (and it really did with a similar bug also yield a
content shift). So, it should actually be "grave".
> Vincent Lefevre wrote:
> > > Nevertheless, there is an even partially persistent workaround: Press
> > > Ctrl-L inside mutt and the problem vanishes even until after the next
> > > detaching and reattaching. Only restarting mutt inside the screen
> > > session and then detaching and reattaching again causes it to show up
> > > again. Hence downgrading the severity.
> >
> > This is incorrect.
>
> Well, then we either see different issues or this is even more a
> corner case which requires more variables to have the right values
> (font availability maybe? init system maybe? sysvinit here.) than we
> know so far.
Perhaps font availability. Or terminfo settings. I doubt concerning
the init system.
Also, you need more than the simple test case to produce corruption
without quitting the current screen window.
> > With my incoming mailbox, the bug is reproducible
> > after doing Ctrl-L. For instance, Page Up + Page Down yields display
> > issues, e.g.
> >
> > 2931 N 2016-11-30 ...
> > 2932 2016-11-30 ...
> > 9337 N + 2016-11-30 ...
> > 2934 N + 2016-11-30 ...
> >
> > Also, switching screen [obvious stuff deleted] also yields upward
> > shift.
>
> Not here either. Ctrl-L works fine here permanently until I quit
> mutt — in both, urxvt and gnome-terminal.
Even when creating a new window and switching to the first one?
> So it's not even that the symtomps are slightly different inside an
> urxvt since we see even different behaviour inside gnome-terminal. And
> as mentioned above, I'm not even able to reproduce these issues in
> uxterm at all (as I don't see the wide character there despite it
> should be possible as it is in urxvt.
Actually that's strange that on your machine, uxterm yields a
different behavior than the other terminals. It seems a local
issue. It seems that your uxterm doesn't support wide characters.
Note that I get a similar behavior with xterm, uxterm, urxvt,
GNOME Terminal and aterm. The behavior is OK with mlterm, but
it doesn't support wide characters, i.e. the U+1F534 character
takes only 1 column; but this mlterm behavior yields other display
problems in other contexts, like with zsh and Mutt (where wrapping
and clipping isn't done at the right place) because applications
assume 2 columns.
> So I'm no more sure that we actually look at the same issue.
I think that's the same, but this can more or less yield
undeterministic behavior depending on the context. And you
need a terminal that supports wide characters.
> Do you by chance know which font you use in uxterm?
AFAIK, it is "fixed". It seems to be the same as "6x13".
At least, the problem is reproducible with it. Well, this
may be more complex than that, since xterm uses a different
font for wide text:
-fw font
This option specifies the font to be used for displaying wide
text. By default, it will attempt to use a font twice as wide
as the font that will be used to draw normal text. If no
double-width font is found, it will improvise, by stretching
the normal font. This corresponds to the wideFont resource.
> > One major problem is that due to the shift, the arrow can be on the
> > wrong message (the arrow is at the right place, but the contents had
> > been shifted upwards), and if I type 'd' to delete the message, the
> > D mark appears on the wrong message for the same reason.
>
> It would be an issue if you can't fix that with Ctrl-L. But even if it
> comes back more often for you than for me, Ctrl-L seems to help at
> least immediately as I understand your mail.
That's too unpredictable. I recall that the display corruption is
not always visible at first sight, and it may be too late when it
is noticeable. So, one would need an automatic Ctrl-L after each
character sent to the terminal (well, that's worse as it hides
Mutt error messages).
> E.g. the attached mbox with a single spam message causes the issues
> you described for me (even without a wide character as far as I can
> see), but only with screen in Wheezy and no more with screen 4.4.0-6
> from Sid. So I'm actually a little bit surprised that still see this
> issues in Sid with the same intensity as I see them only on Wheezy.
Note that Mutt has changed in sid after I reported bugs that
yielded display issues in GNU screen in particular (but also
even without screen, though these were mainly wrapping / clipping
issues). The cause was characters with wcwidth = 0, such as LTR
and RTL marks and some other special "characters". But this was
mainly a bug in Mutt, which sent meaningless / unsupported
characters to the terminal (ncurses doesn't even support bidi
text). In the present case, double-width characters are standard
meaningful characters, so that I doubt that discarding them in
Mutt would be OK (some users could complain).
--
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)
