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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

On 2022-11-09 at 16:58:32, Eric Sunshine via GitGitGadget wrote:
> From: Eric Sunshine <sunshine@sunshineco.com>
> 
> Although the macOS Terminal.app is "xterm"-compatible, its corresponding
> "terminfo" entry neglects to mention capabilities which Terminal.app
> actually supports (such as "dim text"). This oversight on Apple's part
> ends up penalizing users of "good citizen" console programs which
> consult "terminfo" to tailor their output based upon reported terminal
> capabilities (as opposed to programs which assume that the terminal
> supports ANSI codes).
> 
> 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.

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.  However,
that kind of behaviour does result in breakage when the canonical
terminal for that type (in this case XTerm) implements new features that
aren't supported in other implementations.

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

> +	if ($ENV{TERM} =~ /\bxterm\b/) {
> +		%COLORS = (bold  => "\e[1m",
> +			   rev   => "\e[7m",
> +			   reset => "\e[0m",
> +			   blue  => "\e[34m",
> +			   green => "\e[32m",
> +			   red   => "\e[31m");
> +		return \%COLORS;
> +	}

[0] *-direct is what's typically used by ncurses for true colour
variants.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]