Re: [dev] [st] revised mouse handling/reporting

From: Bert Münnich <ber.t_AT_gmx.com>
Date: Fri, 3 Jun 2011 12:41:36 +0200

On 03.06.11, Aurélien Aptel wrote:
> On Thu, Jun 2, 2011 at 2:28 PM, pancake <pancake_AT_youterm.com> wrote:
> > I wonder if those patches are going to be commited.. I find them right.
> > But it's about the third patch in a week without any reply..
>
> I've already committed some of them them locally, not finished yet.
> The reverse video one doesn't behave like xterm on my machine.

You're right, xterm does a lot more than just reversing the default fg
and bg colors. It checks the fg and bg colors and also switches colors
'near' them, i.e. if the bg color is white, then color '\e[37m' is also
changed to black (the normal fg color).
I think that this behaviour is problematic, because color '\e[37m' is
often used as light gray instead of white.

rxvt-unicode is a lot more simpler. It behaves in the same way as my
patch: simply reversing the default fg and bg colors. All the others fg
and bg colors remain untouched.

A nice example to see the difference is alsamixer, which uses a black bg
on the whole screen. My patched st and rxvt-unicode display it as black
in normal and reverse mode, whereas xterm flips the background to white
when in reverse mode (if the normal bg is white).
I prefer the behaviour of rxvt-unicode, because it's simpler and because
I think, that an application, which requests a black bg, should get it
in either mode.

Another question is wether to change the border. rxvt-unicode doesn't
change it when in reverse video mode (so does my patch), but xterm does.
This can easily be fixed, though.
Received on Fri Jun 03 2011 - 12:41:36 CEST

This archive was generated by hypermail 2.2.0 : Fri Jun 03 2011 - 12:48:03 CEST