>I think the mistake here is in applying coloring to stderr.
>Messages on stderr should avoid the use of control sequences
>that may obscure meaning on some terminals or redirection
>targets.
On the other hand, the color does provide obvious visual clues to
what's working properly and what's
Andrew Church wrote:
>
> ... In a more general sense, it might be
> good to do two passes over the entire command line, where the first one
> just picks up critical options (like --no_log_color) and has tc_log_*()
> disabled entirely, and the second one does normal option processing. That
> way,
>in CVS HEAD we already have --no_log_color, but that isn't enough
>since this doesn't address at all 1) and considering 2)
>we can have this situation:
>
>transcode --no_log_color -V yuv420p [...]
> gives sane behaviour
>transcode -V yuv420p --no_log_color [...]
> doesn't work as expected.
>
>I
Hi,
before to get dirty with the new/old bug rush I'd like to discuss some
issues that have long-standing patches here on my CVS working copy.
The first issue is trivial but somewhat tricky. I'd like allow to disable
colorized logging (I've received some private requests for that).
Seems easy bu
