[PATCH] color: use ui.formatted() to test TTYness, not sys.stdout.isatty()

[Christian Ebert]

* Danek Duvall on Tuesday, May 03, 2011 at 11:47:03 -0700
> Matt Mackall wrote:
>> On Tue, 2011-05-03 at 10:41 +0200, Martin Geisler wrote:
>>> Christian Ebert <blacktrash at gmx.net> writes:
>>>> xterm-256color: ok
>>>> screen-256color: control chars
>>>> nsterm-16color: control chars
>>> 
>>> I'm also seeing control chars in my Eterm with TERM set to both 'Eterm'
>>> and 'Eterm-color'.
>> 
>> I'm guessing this discussion is really about Danek's earlier change to
>> consult termcap rather than assume ANSI-style escape sequences, and not
>> Augie's change to properly check isatty() at startup. cc:ing Danek.
> 
> Well, this is cute.
> 
> I assume that Christian and Martin are using the -R flag to less?  Its
> cousin, -r, allows all control sequences through and hence may result in
> the screen being improperly painted.  The -R flag filters out all control
> sequences other than the ones it thinks are "ANSI color" sequences.

I tried -r, but it "feels" unreliable.

> The problem is that its heuristic for determining which sequences are for
> changing color are thrown off by the nsterm-16color and screen-256color
> terminal descriptions, where sgr0 is set to \E[m^O.  Less assumes by
> default that color sequences end in the character "m", which happens to be
> the case for xterm-256color, which presumably borrowed that from ansi
> (although the full escape sequence isn't the same).
> 
> You're supposed to be able to override this by setting LESSANSIENDCHARS
> appropriately, but I can't figure out how to make it work.  Setting it to
> "m^O" (where that's a literal control-O) doesn't seem to do anything, and
> putting simply "^O" there makes the color go away, too.

I haven't looked into how python curses works, but - as a shot in
the dark - this propagates nicely into less -R:

printf '\e[0m\e[34m%s\e[0m\e[0m\n%s\n' "blue" "no color"

So, in my cluelessness I wonder where the ^O comes from or why
it's there ...

> I'm not sure what the right fix is here, but I'm pretty sure the fix is off
> in less's court -- anything that gets information from terminfo and pipes
> the result to less will cause this to happen.

I'm fine with playing around with less -r or just go back to ansi
mode, but I guess some users will be surprised.

c
-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions