>>>>> "F" == FRIGN <dev_AT_frign.de> writes:
F>> No, seriously. If you bring up a point, and we discuss it, we
F>> prefer discussions which cut the bullshit and get to the point
F>> of the problem - or - non-problem. Don't confuse this with being
F>> habitutional, it's just that we have agreed on ways to develop
F>> software and it's important to discuss patches like this if they
F>> fit to the suckless concept or not. Since you already wrote a
F>> patch, I suppose you have strong reasons to support this change
F>> and I'm really interested to find out in which case this might
F>> be useful.
Thank you for the warm words. After second look I don't feel that this
list is unfriendly, even quite the opposite :-)
I will describe cases why I need it:
1. I had bold shell prompt, which was black in all virtual terminals I
have used so far. When I run st first time the first thing that
caught my eye was the _gray_ prompt. It was looking awfully on gray
background.
Now I have changed prompt to use color, but first impression was
spoiled.
2. When you run 'top' in st with black fg and #c0c0c0 fg in st you will
see that it doesn't look as good as in other terminals with the same
fg/bg
3. VIM status line (which displays mode like ---INSERT--) is displaying
the messages in gray instead of black.
4. man output is using bold faces extensively, and in st I see all
headers as gray
(by the way I just noticed that st is also brightening underline
text, while other terminals don't)
5. I think that's enough (I think I can find more examples of
inconsistent behavior if provided examples are not convincing)
F>> Imho, checking if the default color has been altered just
F>> invites nasty edge-cases and generally bloats the code up
F>> unnecessarily. However, I'm open for new ideas.
I love symmetry in code too, and it's disappointing when new
circumstance does not fit into an elegant model. But if such behavior is
expected by programs, probably it worth to be implemented.
My solution is not only possible, I believe there are other ways to do
it. What if to allocate foreground color outside of first 256 entries,
then color cannot be set with an ANSI sequence, and we can check if
default color was altered just by comparing fg to defaultfg. Also
fgcustcolor won't be needed (and errors when we forget to set/reset it
are won't be possible).
Let's just decide, don't you (community) like the whole idea or just
current implementation (patch). If it's just the implementation, I think
I can develop my idea from the past paragraph to new patch.
--
A mari usque ad mare
Received on Tue Apr 15 2014 - 22:45:15 CEST