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.

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.

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.

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