terminal-colors.d and termname

terminal-colors.d and termname

[Karel Zak]

 Hi,

 I'd like to support terminal names ($TERM) in terminal-colors.d,
 because the current implementation does not care about terminal
 types, so you can disable/enable the colors only globally for all
 terminals. That's stupid, because xterm-256color is not the 
 same thing as vt100, etc.

 possible ways:

 1) add terminal name to the file names, for example

    touch terminal-colors.d/dmesg@vt100.disable

 The disadvantage is that there is huge number of terminals and 
 this concept does not allow to use patterns (e.g. fnmatch() patterns 
 like xterm-*). But I think the patterns are unnecessary, because people
 usually use very small set of terminals (serial line, ssh, xterm), so 
 force users to use whole terminal names is no so big problem.

 The advantage is the we can use this concept for color schemes and
 support symlinks to reuse the same scheme for a different terminals.
 The nice things is also that one readdir() is enough to get whole
 configuration.

   echo "error red standard" > dmesg@xterm.scheme
   ln -s dmesg@xterm.scheme dmesg@linux.scheme

 2) use sub-directory

    /etc/terminal-colors/<termname>/dmesg.disable

 but it's less readable (you need "ls -R" or "find") and use symlinks
 will be nightmare.


 3) store the terminal names (or patterns) to the files

    echo "TERM vt10*" >> dmesg.disable

 The same way uses coreutils DIR_COLORS. This concept means that we
 have to always parse the files and you cannot easily create two
 independent color schemes for the same util as there is only one
 'dmesg.scheme', so we will need more advanced file format with
 multiple sections, etc.

 4) ?


 I prefer 1) because it's KISS concept and we have a chance to see
 this way supported by another projects too.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: terminal-colors.d and termname

[Sami Kerola]

On 29 April 2014 11:46, Karel Zak <kzak@redhat.com> wrote:
>  I'd like to support terminal names ($TERM) in terminal-colors.d,
>  because the current implementation does not care about terminal
>  types, so you can disable/enable the colors only globally for all
>  terminals. That's stupid, because xterm-256color is not the
>  same thing as vt100, etc.
>
>  possible ways:
>
>  1) add terminal name to the file names, for example
>
>     touch terminal-colors.d/dmesg@vt100.disable
>
>  The disadvantage is that there is huge number of terminals and
>  this concept does not allow to use patterns (e.g. fnmatch() patterns
>  like xterm-*). But I think the patterns are unnecessary, because people
>  usually use very small set of terminals (serial line, ssh, xterm), so
>  force users to use whole terminal names is no so big problem.
>
>  The advantage is the we can use this concept for color schemes and
>  support symlinks to reuse the same scheme for a different terminals.
>  The nice things is also that one readdir() is enough to get whole
>  configuration.
>
>    echo "error red standard" > dmesg@xterm.scheme
>    ln -s dmesg@xterm.scheme dmesg@linux.scheme
>
>  2) use sub-directory
>
>     /etc/terminal-colors/<termname>/dmesg.disable
>
>  but it's less readable (you need "ls -R" or "find") and use symlinks
>  will be nightmare.
>
>
>  3) store the terminal names (or patterns) to the files
>
>     echo "TERM vt10*" >> dmesg.disable
>
>  The same way uses coreutils DIR_COLORS. This concept means that we
>  have to always parse the files and you cannot easily create two
>  independent color schemes for the same util as there is only one
>  'dmesg.scheme', so we will need more advanced file format with
>  multiple sections, etc.
>
>  4) ?
>
>
>  I prefer 1) because it's KISS concept and we have a chance to see
>  this way supported by another projects too.

Hi Karel,

Does this image summarize the logic that you are describing?

http://ut3.org/~kerolasa/ul-bikeshed.png

What comes to proposed options (IMHO) 1 seems to better than 2 or 3 to
find yes/no answers. For matching meanings with colors some sort of
syntax is probably needed, such as "error red standard" where a color
red seems to mean an error; which leaves it to be commands problem to
determine what is an error.  I do not know what you meant with word
standard.

Over-complicating a bit, or forgetting KISS for now. There seems to be
nearly infinite colors, and possibly infinite meanings. Designing an
interface that will support such may result to be too difficult to
understand. Maybe limiting meanings to a finite set, such as what
syslog has done with levels and facilities, gives enough flexibility
without being impossible to use. Sticking to syslog definitions has
one thing favoring such decision; unixian people are already familiar
with the concept. Downside is that some syslog keywords (LOG_UUCP)
feel a bit legacy. That in mind the syntax could look something like

facility:level:#FFFFFF
facility:level:red

where the later is using the named colors there happens to be. Was
that too beoynd KISS?

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: terminal-colors.d and termname

[Karel Zak]

On Tue, Apr 29, 2014 at 05:52:28PM +0100, Sami Kerola wrote:
> Does this image summarize the logic that you are describing?
> 
> http://ut3.org/~kerolasa/ul-bikeshed.png

 Probably.

> What comes to proposed options (IMHO) 1 seems to better than 2 or 3 to
> find yes/no answers. For matching meanings with colors some sort of
> syntax is probably needed, such as "error red standard" where a color
> red seems to mean an error; which leaves it to be commands problem to
> determine what is an error.  I do not know what you meant with word
> standard.

 <class> <foreground> <background>

the same uses ls(1) DIR_COLORS.

> Over-complicating a bit, or forgetting KISS for now. There seems to be
> nearly infinite colors, and possibly infinite meanings. Designing an
> interface that will support such may result to be too difficult to
> understand. Maybe limiting meanings to a finite set, such as what

 The <class> is a string defined by util and only the util has to care
 what the string means. We don't have to be generic.

> syslog has done with levels and facilities, gives enough flexibility
> without being impossible to use. Sticking to syslog definitions has
> one thing favoring such decision; unixian people are already familiar
> with the concept. Downside is that some syslog keywords (LOG_UUCP)
> feel a bit legacy. That in mind the syntax could look something like
> 
> facility:level:#FFFFFF
> facility:level:red

Now we have

  #define DMESG_COLOR_SUBSYS	UL_COLOR_BROWN
  #define DMESG_COLOR_TIME	    UL_COLOR_GREEN

all I want to use is

  #define DMESG_COLOR_SUBSYS "subsys"
  #define DMESG_COLOR_TIME   "time"

  cl = colors_get_color(DMESG_COLOR_TIME);
  fputs(cl, stdout);

where in the dmesg.scheme will be 

  subsys brown 0
  time green 0

and in dmesg.1 man page will be explained what does it mean "time"
and "subsys". (For now let's ignore that we will need some hardcoded 
defaults.) 

The format of the <class> string depends on the util, I don't see
problem to support for example:

  kern.err red 0

for dmesg.

> Was that too beoynd KISS?

 Yes :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com