Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?

From: [email-masked] (Richard Sandilands)
Date: Sun, 06 Sep 2009 19:42:50 +1000

Hi there

Am just playing with colors.yaml and was looking to change the colors of the
highlight line that indicates a selected thread in inbox view.

Is there a setting for this element?

-- 
Richard Sandilands

---

From: [email-masked] (William Morgan)
Date: Sun, 06 Sep 2009 06:07:48 -0700

Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
> Am just playing with colors.yaml and was looking to change the colors
> of the highlight line that indicates a selected thread in inbox view.
> 

Currently the highlight color is generated programmatically, so there's
no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa
line 82) if you want.

Ideas on how to move this configuration to colors.yaml (or some other
configuration mechanism) welcome.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Carl Worth)
Date: Tue, 08 Sep 2009 13:50:52 -0700

> no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa

Thanks for pointing this out. The highlight color has been one of the
last color annoyances for me, but I hadn't done the effort to find
this in the code yet.

> configuration mechanism) welcome.

What I think I would really like is a mode where none of the
foreground colors/attributes change at all, (it seems distracting to
have the text invert while trying to process mail quickly).

Instead, I'd like the highlight to be a subtle change in the
background color, (but still light or dark like the background so that
the foreground colors are all still readable).

I poked around at this, and my terminal does have two variants of each
of 8 colors available (one brighter than the other), so it seemed like
I should be able to use one as the normal background and one as the
highlight background. But on looking closer, it appears that the
terminal color support here is to name the 8 different colors and to
select the variant for each with the bold attribute. So if I'm
understanding that correctly, that's 16 colors available for the
foreground, but only 8 for the background. That's frustrating.

Such a limited color selection is almost unimaginable with hardware
capability today. (I do see references to "xterm-256color"[*] terminal
definitions. Could sup start depending on things like that? Are there
users of sup using the Linux console or so, and does that support
256-color escape codes?).

Anyway, I gave up for now and decided not to use color for highlight
at all. Instead, I did:

  def highlight_for fg, bg, attrs
    [fg, bg, attrs + [Curses::A_UNDERLINE]]

I should figure out how to make the underline vs. color choice for
highlighting to be a configuration option in order to propose this as
a proper patch. But I still would prefer a subtle change in the
background color instead of an underline if anyone can figure out how
to give me that[**].

-Car

[*] And even 256 colors is antiquated. Anything requiring a fixed
palette is very constraining on an application author today.

[**] Of course, one way is to go away from a curses-based
interface. That might very well make sense in the future where sup is
implemented as a protocol and we can easily have multiple clients. For
me, a graphical client won't be of any interest unless it allows full
keyboard control exactly as sup does, but if it does that and renders
text as well as my terminal, I could imagine using it.

---

From: [email-masked] (William Morgan)
Date: Wed, 09 Sep 2009 07:30:43 -0700

Reformatted excerpts from Carl Worth's message of 2009-09-08:
> So if I'm understanding that correctly, that's 16 colors available for
> the foreground, but only 8 for the background. That's frustrating.

Yup. Curses is happy to welcome you to 1982!

> capability today.

FWIW, most terminal emulators allow you to tweak the actual colors that
the curses colors refer to. So you have some flexibility about the
actual colors, just a small palette.

> (I do see references to "xterm-256color"[*] terminal definitions.
> Could sup start depending on things like that? Are there users of sup
> using the Linux console or so, and does that support 256-color escape
> codes?).

I'm not sure. I suspect no, but I would be interested in learning more.

> a proper patch.

I think the only patch I would accept at this point for tweaking the
highlight would be a new hook.

> Of course, one way is to go away from a curses-based interface. That
> might very well make sense in the future where sup is implemented as a
> protocol and we can easily have multiple clients.

That is one of the goals.

> For me, a graphical client won't be of any interest unless it allows
> full keyboard control exactly as sup does, but if it does that and
> renders text as well as my terminal, I could imagine using it.

I agree completely.