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

[Danek Duvall]

Christian Ebert wrote:

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

It's probably just fine when paging hg output, as it won't be doing
anything odd that will throw off less's idea of where the position is.  But
I agree; I'd much rather use -R.

> > 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 ...

Like I said, it comes from the terminfo entry for your terminal.  See the
output of "infocmp $TERM", and it's right there, in sgr0.  It has nothing
to do with python or (n)curses; it's a fundamental problem with the way
that less tries to figure out which control sequences are related to color
and which aren't.  You'll see exactly the same thing with any other program
that emits terminfo-based color whose output you pipe through less.
Unfortunately, I don't know of any program that does that -- colorized ls
uses ansi color sequences, and all other programs I use that use color do
it with terminfo, but none of them are usefully paged.

Danek