Add a terminfo file declaring TrueColor support

[cac04]

Alacritty supports true color (24bit) escape codes. There isn't an official terminfo entry for this (yet?) but tmux has an unofficial one: Tc

This is used by others, e.g. st

[jwilm]

Thanks for the PR! Since you're adding a terminfo file, would you mind also including these?

	ritm=\E[23m,
	sitm=\E[3m,

It's somewhat common for xterm terminfo files to not declare them.

[jwilm]

It would be good to include an alacritty-256color variant as well.

[cac04]

I've done that now. The alacritty-256color entry is just a duplicate of the alacritty entry. Is that what you had in mind? It seemed sensible, since the original is based on xterm-256color anyway.

[jwilm]

Awesome, thank you!

[jonhoo]

FWIW, just pushed an Arch package to install just the terminfo files: https://aur.archlinux.org/packages/alacritty-terminfo-git/

[maximbaz]

@jwilm @jonhoo does it make sense to change now the default value of TERM in alacritty.yml to be alacritty-256color?

And/or also update this behavior:

TERM env customization.
If this property is not set, alacritty will set it to xterm-256color.

[jwilm]

I would rather keep it as xterm-256color for a couple of reasons:

1. Users won't have this terminfo installed by default. xterm-256color will "just work."
2. Some programs break or have extra configuration needs when TERM is not xterm-something.

At the point a user is savvy enough to install the terminfo, it's fine to require a confit change.

[jdebp]

Some points:

• Strictly speaking you should not be deriving a non-256-colour terminfo entry from xterm-256color whilst having a separate 256-colour entry as well.
• Note that there's a difference between xterm+256setaf and xterm+256color. You need to base this choice upon whether alacritty allows the indexed colour palette to be changed with control sequences.
• An animation in Rendering artifacts neovim/neovim#6849 leads me to believe that alacritty does not have BCE. If that is the case then you should definitely not be blithely deriving from xterm-256color.
• Don't make the mistakes that Marc Lehmann, Unicode rxvt developer, did:
  • One cannot blithely make up terminal type names. There are libraries that process terminfo on systems out in the wild that do not permit terminal names to exceed some rather short maximum lengths. This is one of the reasons that the name rxvt-unicode-256color is described as not portable.
  • Don't blithely use tic to compile your terminfo file and assume that it does the right thing. tic has some special behaviour, described in its manual page, when run as any user that can write to /etc/terminfo. Make packagers' lives easy and ensure that you run tic so that it puts the compiled terminfo database record into the right place in your build area, whether the running user can write to /etc/terminfo or not.

I suggest that you improve to something like (at minimum, there's probably a lot more to do):

alacritty-basic|alacritty base,
        bce@,
        Tc,
	ritm=\E[23m,
	sitm=\E[3m,
        setrgbf=\E[38;2;%p1%d;%p2%d;%p3%dm,
        setrgbb=\E[48;2;%p1%d;%p2%d;%p3%dm,
	use=xterm-basic,

alacritty|alacritty
	use=alacritty-basic,
alacritty-256color|alacritty with 256 colors,
	use=alacritty-basic, use=xterm+256setaf,

setrgbb and setrgbf are extensions proposed in 2013. Some terminal emulators also accept the standards-conformant form of SGRs 38 and 48, where the sub-parameters are separated by colons rather than semi-colons. It would be welcome if alacritty joined their ranks.

[nicm]

@jdebp if you go off xterm-basic you will also want some or all of xterm+pcfkeys, xterm+sl, xterm+tmux, ecma+strikeout, indn/rin depending what your terminal actually supports.

[cac04]

@jdebp Thank you very much for that (and sorry for taking so long to comment, non-hobby-life interjected).

Just to clarify, I derived from xterm-256color in this case because alacritty was already declaring itself to be xterm-256color. So, even if this is not quite correct, it is no worse than the pre-existing situation (and, I think, better because it allows TrueColor to work). I completely agree that this needs more work.