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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 10, 2022, 02:40 UTC
Message-ID: <Y2xkpJj4jLqfsggL@tapette.crustytoothpaste.net>
In-Reply-To: <b85b28e5a6beea97c149f0b9de6ba8d0a4a7c1f9.1668013114.git.gitgitgadget@gmail.com>

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

Show 16 quoted lines

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

Show 9 quoted lines

> +	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