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

Danek Duvall duvall at la-z-boy.comfychair.org
Tue May 3 18:47:03 UTC 2011


Matt Mackall wrote:

> On Tue, 2011-05-03 at 10:41 +0200, Martin Geisler wrote:
> > Christian Ebert <blacktrash at gmx.net> writes:
> > 
> > > Played around some more. Seems it depends on the value of $TERM. Here
> > > are the results for the $TERM values I mostly use:
> > >
> > > 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.

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

Danek


More information about the Mercurial-devel mailing list