Re: [PATCH 0/3] Various clean up in preparation for libtextstyle

[Bruno Haible]

Hi Akim and HS,

> > OTOH, I found all of these instances quite annoying, and took pains to
> > turn them all off.  As they say, YMMV. :-D
> 
> Yep, but it's always good to know.  Thanks for reporting.

Yes, in some environments colored text comes out unreadable.

> > If forced to write one, my version of diagnostics.css would be:
> > 
> >     * { }
> > 
> > :-P

An empty diagnostics.css file has the same effect.

If many people report the same thing, we could have a single environment
variable for all libtextstyle-enabled programs, that would turn off styled
output.

> > Whoa. IMNSHO, when a program needs to parse CSS just to be able to print
> > diagnostic messages, then something has gone truly rotten in the state
> > of programming.

You express this thought in a funny way. But things are getting more dynamic:
The TERM variable gets passed down through ssh automatically; therefore you
might be using the programs on the same machine in different TERMs at different
times.

Many programs nowadays have a kind of "initialization file" (think of
~/.bashrc, ~/.git/config, ~/.wgetrc etc.). The style file is like this.
It is written by a human, and edits are expected to be effective immediately.
Therefore it has to be parsed before use.

> if libtextstyle gets widespread

libtextstyle will be distributed and installed with gettext. Thus it will get
widespread in the sense that it will be installed on many systems.

> But moving all the output functions on top of ostream would be
> quite painful.  I really wonder if I should not try to synchronize
> the ostream for style, and the FILE* for output.

What I can offer are two methods on the styled ostreams:
  - a flush method that puts the target into the default state, so that
    you can print any string you like (including newlines) through a
    FILE*,
  - a flush_to_current_style method that puts the target into the style
    that corresponds to the currently active CSS classes, so that you
    can print any string that does NOT contain newlines.

The reason for this restriction is that many terminals behave oddly
if you emit a newline while some background colors or other attributes
are in effect.

> I will try to play with flush and simultaneous
> uses of stderr and styled_ostream and see how it goes.

I can implement the above mentioned methods within a couple of days.

> getopt is especially tricky, since I want to use getopt to set up
> libtextstyle, and I want to use libtextstyle for errors.
> If I want this to be consistent

Ouch :) Never thought at this. But you are right: It should better be
consistent. Once a user expects to see errors in a red color, they will
not look at it so closely if it is not in red color.

Bruno