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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 10, 2022, 22:21 UTC
Message-ID: <Y215ZKz2iZWJCYo3@tapette.crustytoothpaste.net>
In-Reply-To: <CAPig+cTL4x45E2a0RbpO2ntPo08K8hQ2wxcXm=QesqtYqxpvaw@mail.gmail.com>

On 2022-11-10 at 03:37:16, Eric Sunshine wrote:

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

I'd say we should do nsterm, nsterm-256color, and nsterm-direct.

Show 6 quoted lines

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

It's present in newer ncurses, so I expect it will make its way to macOS eventually. I don't know whether Apple's version of it will contain the `dim` capability, but on Debian all three xterm variants do.

It sounds like Apple is specifically limiting their capabilities for some reason when upstream ncurses doesn't. I can't say why that is, but perhaps it's for compatibility. Debian had to do that for one release with screen* when Screen added support for some new feature but tmux had not.

Show 7 quoted lines

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

Maybe this, then?

/(xterm|nsterm)(-(256color|direct))?|xterm-new/

That matches the three special variants of each one here plus xterm-new.

Show 5 quoted lines

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

Sure.  I would also prefer to avoid that.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA