GitLab

Small change to use `x->new` instead `new x`.
The $| usage has been marked as 'no critic' as this is explicitly
intended here.

The configuration has been added so that we can do the linting of the
code in a sensible way.

If there's an error writing to stderr we can easily end up exiting
out shell. That may make it harder to debug. In the future there may
need to be much better handling of failure cases!

The example command was missing the switch --examples!

The stderr-colour.sh script will quite happily redirect the output,
and leave the rest of the prompt alone. This is now documented!

The --examples switch and the usage with a single command are now
documented.

Without colours we were getting messages about invalid output. This
can be fixed by just ensuring that we use '' instead of undef for
no colour.

The warning theme isn't that special, but will show the effect of
adding a representative symbol instead of a grouping symbol.

The --examples can show examples of the themes for the symbols and
the current configuration. As part of this, it is now also possible
(internally only) to change the prefix before or after the output,
and before or after the message. This may be useful in providing
some styles of output, but there isn't a configuration for it as
yet.

Configuration now allows the selection of themes for the line and
inline output, and for the colours of symbols and messages. This
should allow the output to be rendered in a more flexible manner.

The themes themselves are still hard-coded, but they do allow
a little bit of flexibility in order to be extended in the future,
eg through a configuration file.

The message is now coloured red, but the symbol is magenta. It had
been red for both, but I wanted to try to separate the two. Seems
to work, although it's not at all configurable.

The flush would leave the queued content present, so we would get a
repeated string output as the next output happened. We now clear
it.

The sysread() function does not really work on UTF-8 encodings for the
file handle. It could read a partial sequence and cause badness. Instead
we should read raw input and then decode once we get a full line input.
This should make it a lot more reliable except if the input is not valid
utf8. Not sure what happens then.

When a CR is encountered, we're still in the same line, but we want
to be able to output the surround on all the output. This means that
we need to process the CR output separately before falling back into
the regular inline/multi-line error output handler.

This has been implemented here and appear (on tests with fdupes, and
simple error output) to work relatively well, even when the delay is
present.

The colouring tool will colour a stream of input and write it to
output, prefixing lines with a [ style marker, and inline output
with <> surrounding it.

It's really just a proof of concept!