Comment 8 for bug 1161826

https://github.com/daveewart/colordiff/pull/6 describes the use cases considered for the previous change which is not quite the same as yours.

I'm often finding myself fielding conflicting patches from users with different expectations about how colordiff should behave and that makes progress tricky. (There are situations where retaining colours through pipes can be helpful: some 'while'/'for' loops I've been shown, for example).

My general approach is, therefore, that unless a patch is clearly changing a *fault*, I'd prefer to leave the default behaviour untouched. With that in mind, if some colordiff users see alternative behaviours as more correct, I'm open to including additional *options* in the code, so long as the default behaviour of such options is 'no change to existing behaviour'. This should allow all users to configure the stock colordiff to their own requirements without upsetting existing users who like the existing behaviour.

This is quite a tricky balancing act and over the years I've had patches from user A asking to changing the behaviour of pipes/TTY, followed by a patch from user B *reverting those very same changes*! :-) And, not long afterwards a patch from user C with a patch similar to user A etc. :-D

I see where you're getting at with your code: remove colour from everything going to a pipe by default and enforce a pager: the current release version allows colour to a pipe precisely so that it can be piped to a pager. I see your idea behind including a call to 'less' in the code, but that in itself is a change of behaviour which might blow up the face of some other long-support expected behaviour ...

Sorry to reject the patch and I totally understand your reasons: hopefully the above explains why I can't simply consider your contribution as a direct improvement. Thanks again, Manuel; good luck with colordiff :-)