Colorizations made using piping to external tools suffer from lack of semantic information about the output. Take colordiff for example - in many places it parses (regex's) the output hoping it does The Good Thing, but still its just hoping (and fails sometimes).
If there was an output version that was semantically complete (e.g. some kind of markup on normal output) for automatic interpretation, it would always be easy to achieve colorization (and other mangling) through external tools. It would also make those tools way simpler, since they would just re-interpret and not heuristically regex through the human-readable output. Moreover, in such case, there would be no problems with signaling etc. In the case of colordiff, it actually does a good job thanks to the largely semantically marked-up output of diff, but in places that are not marked-up (i.e. other information than what goes in and out of a file), it mostly does for English, but miserably fails for other languages (though, it would do better using gettext for i18n). Dnia 5 maja 2013 8:07 Sergey Poznyakoff <[email protected]> napisaĆ(a): > Paul Eggert <[email protected]> ha escrit: > > > I'm not a big fan of colorization, > > Neither am I, to tell you the truth. > > > if Sergey likes the idea > > No, I certainly don't. If really needed it can be done by a program > that invokes tar (e.g. tar-mode in Emacs). > > Regards, > Sergey > >
