Re: [PATCH 1/3] chainlint: sidestep impoverished macOS "terminfo"

[Eric Sunshine <sunshine@sunshineco.com>]

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.