summaryrefslogtreecommitdiff
path: root/commit.c
diff options
context:
space:
mode:
authorEric Sunshine <sunshine@sunshineco.com>2022-11-11 07:34:52 +0000
committerTaylor Blau <me@ttaylorr.com>2022-11-11 16:56:21 -0500
commit5451877f87f8c0c820dd8605e03cb00ea794ca89 (patch)
treec656a3d625b42a742a23fe81a3fa9d6a27e39c37 /commit.c
parent3a79a8085b9d1647bdecf91d60d330ddce5aeb30 (diff)
chainlint: sidestep impoverished macOS "terminfo"
Although the macOS Terminal.app is "xterm"-compatible, its corresponding "terminfo" entries -- such as "xterm", "xterm-256color", and "xterm-new"[1] -- neglect 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). The same problem is present in other Apple "terminfo" entries, such as "nsterm"[2], with which macOS Terminal.app may be configured. Sidestep this Apple problem by imbuing get_colors() with specific knowledge of capabilities common to "xterm" and "nsterm", 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 other terminal types, fall back to querying "terminfo" via `tput` as usual. FOOTNOTES [1] iTerm2 FAQ suggests "xterm-new": https://iterm2.com/faq.html [2] Neovim documentation recommends terminal type "nsterm" with Terminal.app: https://neovim.io/doc/user/term.html#terminfo Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com>
Diffstat (limited to 'commit.c')
0 files changed, 0 insertions, 0 deletions