>>>>> "F" == FRIGN <d...@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