Re: [dev] [st] colors and attributes, general question

From: Christoph Lohmann <20h_AT_r-36.net>
Date: Tue, 23 Apr 2013 17:53:47 +0200

Greetings.

On Tue, 23 Apr 2013 17:53:47 +0200 random832_AT_fastmail.us wrote:
> I'm planning on reworking xdraws and drawregion to draw the background
> and text as separate functions. To do this I need to understand some
> things:
>
> As I understand it, the behavior is to have all attribute effects on
> color (e.g. bold brightening, italic/underline colors) affect only the
> foreground and not the background when in normal mode, and affect only
> the background and not the foreground in reverse (ATTR_REVERSE) mode. Is
> this understanding correct?

ATTR_REVERSE only affects the colors.

> As I understand it, the behavior for MODE_REVERSE is to use RGB color
> inversion, and not bg/fg swapping (so yellow-on-red becomes
> blue-on-cyan, not red-on-yellow) , on all colors _except_ for the
> default bg/fg colors. Is this understanding correct?

MODE_REVERSE is – like it’s name – the reverse of all colors. This is
done exactly, except for the default bg and fg, which people configure
as being the default fg and default bg.

> Is the above outlined behavior actually correct by the standards /
> desirable / does it match the behavior of other terminals? config.def.h
> says " Another logic would only make the simple feature too complex."
> but I find that in making this change supporting the current behavior
> (my understanding as outlined above) is actually more complex (because
> it requires me to duplicate attribute color mapping in both functions)

It’s the simple way of doing all the brigthening and reversing. St is
keeping to what other terminals do. But since none of them keeps to any
standard colors or good behaviour is this what makes st being what it is
– a simple terminal.

> There is also, as far as I can tell, no support for brightening the
> background for ATTR_BLINK.

ATTR_BLINK is by definition not implemented. There shouldn’t be any
pseudo color highlight for it; when it’s implemented it should be right.
The drawing function shouldn’t be interested in the unused attribute
bits.


Sincerely,

Christoph Lohmann
Received on Tue Apr 23 2013 - 17:53:47 CEST