From mboxrd@z Thu Jan  1 00:00:00 1970
From: cworth@cworth.org (Carl Worth)
Date: Tue, 08 Sep 2009 13:50:52 -0700
Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?
In-Reply-To: <1252241877-sup-6125@masanjin.net>
References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
	<1252241877-sup-6125@masanjin.net>
Message-ID: <1252442174-sup-1472@yoom.home.cworth.org>

Excerpts from William Morgan's message of Sun Sep 06 06:07:48 -0700 2009:
> Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
> > Is there a setting for this element?
> 
> 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.

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.

> Ideas on how to move this configuration to colors.yaml (or some other
> 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.