git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	"Eric Sunshine via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH 1/3] chainlint: sidestep impoverished macOS "terminfo"
Date: Wed, 9 Nov 2022 22:37:16 -0500	[thread overview]
Message-ID: <CAPig+cTL4x45E2a0RbpO2ntPo08K8hQ2wxcXm=QesqtYqxpvaw@mail.gmail.com> (raw)
In-Reply-To: <Y2xkpJj4jLqfsggL@tapette.crustytoothpaste.net>

On Wed, Nov 9, 2022 at 9:40 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On 2022-11-09 at 16:58:32, Eric Sunshine via GitGitGadget wrote:
> > Sidestep this Apple problem by imbuing get_colors() with specific
> > knowledge of "xterm" capabilities rather than trusting "terminfo" to
> > report them correctly. Although hard-coding such knowledge is ugly,
> > "xterm" support is nearly ubiquitous these days, and Git itself sets
> > precedence by assuming support for ANSI color codes. For non-"xterm",
> > fall back to querying "terminfo" via `tput` as usual.
>
> Given the regex below, I think the question here is actually whether
> XTerm itself supports these in all its variants (my Debian system lists
> approximately 90 of them), many of which are quite old.  While I don't
> expect most of them to see common use, given the interest some people
> have in retrocomputing, I don't think we can exclude the possibility of
> seeing people use esoteric xterm variants over an SSH (or, perhaps less
> pleasantly, telnet) connection.

I get your drift, but I have to wonder if the retrocomputing crowd is
really going to be crafting Git tests directly on their retrohardware.
(appropriate emoji here)

> Terminal.app actually has its own set of terminal types, nsterm*, which
> are properly used here instead, although I realize that most people
> prefer the xterm* options for compatibility and ease of use.

Hmm, on my machine "nsterm" also lacks the "dim" capability. I see
that Neovim docs recommend "nsterm" with Terminal.app, so perhaps that
ought to be handled specially here, as well. Do you think any
variations other than base "nsterm" are worth special-casing?

> Perhaps, instead of auditing all 90 terminal types, we should tighten
> this to xterm, xterm-256color, and xterm-direct[0]?  That should cover
> the vast majority of use cases in the real world today, including most
> users of macOS and Terminal.app, while avoiding breaking some older
> variants (e.g., xterm-old lacks setaf).

I don't mind tightening which terminal types are handled specially.
"xterm-direct" doesn't exist on my old macOS. Is it present on newer
macOS? If so, does it require special-casing (i.e. does it lack
"dim")? If we don't special-case "xterm-direct", it will fall back to
using `tput` interrogation, which should be fine as long as the
"xterm-direct" terminfo entry is accurate.

I notice that the iTerm2 FAQ also recommends "xterm-new" on macOS, and
that one lacks "dim", as well on my machine. So, it seems that it
should be special-cased too.

Taking all the above into account, perhaps this regex?

    /xterm|xterm-.*color|xterm-new|nsterm/

Of course, the other option is to follow Git's own lead by not
worrying about TERM and `tput` and just assume everyone understands
ANSI color codes. I'm too old-school to feel entirely comfortable with
that approach, but I would entertain it if others feel it is safe
enough.

  reply	other threads:[~2022-11-10  3:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 16:58 [PATCH 0/3] chainlint: emit line numbers alongside test definitions Eric Sunshine via GitGitGadget
2022-11-09 16:58 ` [PATCH 1/3] chainlint: sidestep impoverished macOS "terminfo" Eric Sunshine via GitGitGadget
2022-11-09 22:18   ` Taylor Blau
2022-11-10  2:40   ` brian m. carlson
2022-11-10  3:37     ` Eric Sunshine [this message]
2022-11-10 22:21       ` brian m. carlson
2022-11-10 22:36         ` Eric Sunshine
2022-11-10 22:48           ` brian m. carlson
2022-11-09 16:58 ` [PATCH 2/3] chainlint: latch line numbers at which each token starts and ends Eric Sunshine via GitGitGadget
2022-11-09 16:58 ` [PATCH 3/3] chainlint: prefix annotated test definition with line numbers Eric Sunshine via GitGitGadget
2022-11-09 22:22 ` [PATCH 0/3] chainlint: emit line numbers alongside test definitions Taylor Blau
2022-11-11  7:34 ` [PATCH v2 " Eric Sunshine via GitGitGadget
2022-11-11  7:34   ` [PATCH v2 1/3] chainlint: sidestep impoverished macOS "terminfo" Eric Sunshine via GitGitGadget
2022-11-11 14:55     ` Ævar Arnfjörð Bjarmason
2022-11-11 16:44       ` Eric Sunshine
2022-11-11 17:15         ` Eric Sunshine
2022-11-11 21:56           ` Taylor Blau
2022-11-11  7:34   ` [PATCH v2 2/3] chainlint: latch line numbers at which each token starts and ends Eric Sunshine via GitGitGadget
2022-11-11  7:34   ` [PATCH v2 3/3] chainlint: prefix annotated test definition with line numbers Eric Sunshine via GitGitGadget
2022-11-11 15:03 ` [PATCH 0/3] chainlint: emit line numbers alongside test definitions Ævar Arnfjörð Bjarmason

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='CAPig+cTL4x45E2a0RbpO2ntPo08K8hQ2wxcXm=QesqtYqxpvaw@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).