[Pkg-xfce-devel] Bug#825054: Bug#825054: bug in mutt or a library

Yves-Alexis Perez corsac at debian.org
Mon May 23 11:34:25 UTC 2016


control: reassign -1 mutt

On lun., 2016-05-23 at 12:47 +0200, Adam Borowski wrote:
> > My terminal colour configuration is black on white.
> > After using mutt, the terminal colours are changed to grey on
> > black. Workaround: type "reset" afterwards.
> > Btw. neither xterm nor gnome-terminal mess with the colours, so
> > I suspect, that the error is in xfce4-terminal, not mutt.
> > This behaviour was not present in wheezy.
> 
> This applies to all vte-based terminals (lxterminal, etc).
> 
> As for the behaviour change, it is in mutt or one of libraries it uses, not
> in xfce4-terminal or vte.  Let's, from an unstable system (including the
> terminal) log in to a jessie server, and compare.  With stable mutt, you get
> default fg on default bg, with unstable mutt, grey on black.
> 
> So let's diff the output:
> 
>  \e[43d                   # go to column 1 line 43 (1-based)
>  Mailbox is unchanged.\n  # write a string
>  \e[39;49m                # fg=default, bg=default
> +\e[37m                   # fg=grey
> +\e[40m                   # bg=black
>  \r                       # go to column 1
>  \e[K                     # clear line to the right
>  \e[43;1H                 # go to column 1 line 43 (redundant...)
>  \e[?1049l                # restore cursor position, switch to primary
> screen
>  \r                       # go to column 1
>  \e[?1l                   # switch grey arrow keys to "normal" mode
>  \e>                      # switch keypad arrow keys to "normal" mode
>  Mailbox is unchanged.\n  # write a string
> 
> As you can see, new mutt explicitely sets the colors to grey/black
> immediately after setting them to default/default.  This is the cause of the
> bug you see.
> 
> And why xterm and gnome-terminal don't exhibit it?  It's because of
> \e[?1049l
> which is an xterm extension.  Many terminals don't implement it in the first
> place -- this results in mutt not restoring the screen, which is okay, and
> even if they do, the documentation is really unclear.  Thomas Dickey's
> ctlseqs.txt refers to DECRC, which says just "Restore Cursor".  If you look
> elsewhere for guidance, you'll usually find "restore cursor position".
> I'd say the correct thing is to follow granddaddy vt100 which restored
> colors/boldness/etc as well, but it'd undebatable that confusion exists.
> 
> But let's assume that xterm's interpretation is correct, and we immediately
> change all terminals in Debian unstable to restore colors on DECRC.  The
> problem is, a good part, perhaps even majority, of mutt users don't execute
> it locally but ssh to a mail server elsewhere.  Thus, very often the
> terminal will run Debian stable or oldstable, some derivative (like, say,
> maemo which is EOL thus won't ever change this), some other distribution or
> even a completely non-Linux OS whose terminals we don't have any control on.
> 
> Thus, let's ponder the purpose of mutt's change: it forces grey-on-black
> just to immediately restore it.  That's utterly pointless, regardless of
> whether the restore is expected to work or not.
> 
> My conclusion: whoever we blame, this bug is 100% a mutt regression, and
> needs to be fixed there (or in a library mutt uses).

Thanks for the in-depth analysis. I'm reassigning to the mutt package and
adding the maintainer to recipients (hopefully), copying the full text so they
don't get a cryptic mail about this.

Regards,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xfce-devel/attachments/20160523/7d7ee999/attachment-0001.sig>


More information about the Pkg-xfce-devel mailing list