>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 not. And since transcode's error
messages are not intended for programmatic consumption anyway, I don't
see a problem. (Program-parseable log messages would be a Good Thing,
but are future work, not for 1.1.)
>There should not be any options that require "early
>processing"...
In theory, I'd agree with you. As they say, though--in theory
there's no difference between theory and practice, but in practice...
Especially given the complexity of transcode's command line, I don't
think it's worth the effort to force everything into a single pass until
we can rethink transcode's command line entirely (which is _definitely_
not happening for 1.1).
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
