Re: ANSI sequences produced on non-ANSI terminal

From: Jeff King <peff@peff.net>
Date: Sep 25, 2021, 05:49 UTC
Message-ID: <YU64WQOg/zY7P+Gh@coredump.intra.peff.net>
In-Reply-To: <592a799b-0d16-1615-4737-3c634d029d7f@starwolf.com>

On Fri, Sep 24, 2021 at 04:57:11PM -0700, Greywolf wrote:

Show 14 quoted lines

> On 9/23/2021 14:20, Jeff King wrote:
> 
> > Git doesn't have any kind of list of terminals, beyond knowing that "dumb"
> > should disable auto-color. It's possible we could expand that if there are
> > known terminals that don't understand ANSI colors. I'm a bit wary of having
> > a laundry list of obscure terminals, though.
> 
> Oh, gods, I wouldn't have that at all!  No, I just want it NOT to spit out
> not only the colour codes, but the cursor positioning codes as it seems
> wont to do when I do a fetch.  I'm more than happy to turn coloring off
> (conditional on TERM would be a bonus, however it's done) on my own;
> in fact, I have done so, but the fetch/pull still seem to be messing up
> my screen, with color turned off (unless I'm not turning it off
> *enough*, which is entirely possible).

OK, that makes things a bit easier. The colors, as you noticed, can be disabled by config. The other thing you're seeing is ANSI ESC[K, which is used to clear to the end of line. We use this in a couple places, notably when relaying progress lines from the server (with the "remote:" prefix) which may use carriage-returns to overwrite lines.

See ebe8fa738d (fix display overlap between remote and local progress, 2007-11-04) if you're really interested.

Anyway, there's no config option to disable that. However, we do disable it if TERM is empty or set to "dumb" (and instead just write some extra spaces to clear out the line). So that may be an option, though of course setting TERM=dumb may affect other programs you use.

I don't think it would be unreasonable to have a config option to select whether we use the ANSI or dumb-term version.

Show 9 quoted lines

> > If we built against ncurses or some other terminfo-aware library we could
> > outsource that, but that would be a new dependency. I'm hesitant to do that
> > even as an optional dependency given the bang-for-the-buck (and certainly
> > making it require would be right out).
> 
> Well understood.  Also, not asking for people to jump thru flaming hoops.
> Just trying to figure out how to get git to stop assuming things.
> (as stated, I am aware it could be my fault for not setting variables
> properly all the way).

Nah, it sounds like you actually set the variables correctly. We've just assumed that we can get by with ANSI codes as a lowest common denominator in the modern world, without having to resort to all the complexities of using a terminfo library. It's worked pretty well so far. ;)

-Peff