All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greywolf <greywolf@starwolf.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: ANSI sequences produced on non-ANSI terminal
Date: Fri, 24 Sep 2021 16:57:11 -0700	[thread overview]
Message-ID: <592a799b-0d16-1615-4737-3c634d029d7f@starwolf.com> (raw)
In-Reply-To: <YUzvhLUmvsdF5w+r@coredump.intra.peff.net>

Greetings and thank you ALL for your responses!

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

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

> Obviously you can wrap Git with a script to tweak the config based on the
> current setting of the $TERM variable. It would be nice if you could have
> conditional config for that. E.g., something like:
> 
> [includeIf "env:TERM==xterm"] path = gitconfig-color
> 
> That doesn't exist, but would fit in reasonably well with our other 
> conditional config options.

That is a consideration; and one I had not thought of.

> As far as generating non-ANSI codes, that's all Git knows how to do.

Just need to have it NOT generate ANSI codes, if requested.  I'm certainly
not requesting the world of terminals to be incorporated -- just some
universal readability.

As far as the suggestion to use "screen", I'm not going to be starting up
a screen session every time I log in. :)

				Thank you all very much!

				--*greywolf;

  parent reply	other threads:[~2021-09-24 23:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23  5:21 ANSI sequences produced on non-ANSI terminal The Grey Wolf
2021-09-23 21:20 ` Jeff King
2021-09-23 21:54   ` Junio C Hamano
2021-09-23 22:04     ` Randall S. Becker
2021-09-25  6:45       ` Kevin Daudt
2021-09-24  0:58   ` [PATCH] config: add an includeIf.env{Exists,Bool,Is,Match} Ævar Arnfjörð Bjarmason
2021-09-24 21:07     ` Jeff King
2021-09-24 21:28       ` Junio C Hamano
2021-09-24 21:59         ` Jeff King
2021-09-27 16:30           ` Junio C Hamano
2021-09-27 20:15             ` Jeff King
2021-09-27 20:53               ` Randall S. Becker
2021-09-27 21:37                 ` Jeff King
2021-09-27 21:56                   ` Randall S. Becker
2021-09-27 23:52               ` Ævar Arnfjörð Bjarmason
2021-09-28  0:41                 ` Jeff King
2021-09-28  2:42                   ` Ævar Arnfjörð Bjarmason
2021-09-28  5:42                     ` Jeff King
2021-09-28 19:28                       ` Ævar Arnfjörð Bjarmason
2021-09-28  0:24               ` Junio C Hamano
2021-09-24 23:57   ` Greywolf [this message]
2021-09-25  5:49     ` ANSI sequences produced on non-ANSI terminal Jeff King
2021-10-01 23:17       ` Greywolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=592a799b-0d16-1615-4737-3c634d029d7f@starwolf.com \
    --to=greywolf@starwolf.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.