Completely rework colour: add `colour' and `mono' commands..
commit4a812d7ab8faf67b6eaebd0f7a077335e3347c03
authorSteffen (Daode) Nurpmeso <steffen@sdaoden.eu>
Thu, 3 Mar 2016 15:01:32 +0000 (3 16:01 +0100)
committerSteffen (Daode) Nurpmeso <steffen@sdaoden.eu>
Thu, 15 Sep 2016 13:56:40 +0000 (15 15:56 +0200)
tree83a41baf4f1d1342ab62c19e9e1d3d63ed7222c1
parent32cdd0d4680937791423d269cb4d8962de9b945d
Completely rework colour: add `colour' and `mono' commands..

as well as their counterparts `uncolour' and `unmono'.

v15 and above will be more feature rich (shall they ever be
reached).  The next major release will not happen before 2017.
This is two years.  And since S-nail has become pretty stable and
works pretty well too i'm hoping that it'll attract some people in
these forthcoming years.  Assuming this really happens it seems
best not to use that hacky variable-based colour approach, it was
nothing but a quick hack around new years eve 2013/2014 in order
to honour John Dodson and Ypnose with some coloured output, but to
take some time and implement something that will last.

Like that we can make the colour stuff truly upwards compatible
today and can also support at least font attributes on monochrome
displays, and both with the same configuration, only dependent
upon $TERM.  And even though it looks as if the command names have
been stolen, i really thought about them, but found no other
solution.  The semantics are our own completely, at least.

The only problem that remains:

  - we simply assume `mono'chrome display is available unless
    $TERM is not set or "dumb".
    Ideally we would look into termcap(3) wether we have colours
    and use the termcap(3) sequences for "bold" etc. for
    monochrome displays as a fallback instead.
cmd1.c
cmd_tab.h
colour.c
lex.c
nail.1
nail.h
nailfuns.h
send.c