On Wed, Nov 9, 2022 at 9:40 PM brian m. carlson
[off-list ref] wrote:

On 2022-11-09 at 16:58:32, Eric Sunshine via GitGitGadget wrote:

quoted

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.