termcap: add entry for Alacritty

[svmhdvn]

Converted using tic -C <upstream alacritty.info file> and tested locally with $HOME/.termcap. I'm not very familiar with termcap files, but this seems to work for me, so please do additional testing if needed.

[concussious]

Hi! Thanks for sending a patch. What problem does this solve? I've been using Alacrity on FreeBSD for several years, and haven't noticed anything.

[svmhdvn]

Hi! Thanks for sending a patch. What problem does this solve? I've been using Alacrity on FreeBSD for several years, and haven't noticed anything.

This may be because your configuration of alacritty is reporting a TERM other than "alacritty", e.g. "xterm-256".

Out of the box on other platforms, alacritty reports TERM=alacritty. This requires an updated terminfo/termcap database that contains an entry for alacritty. When I try to ssh into a FreeBSD machine using a default configuration of alacritty on my macos system, it reports this in my motd(5):

No entry for terminal type "alacritty";
using dumb terminal settings.

[concussious]

Out of the box on other platforms, alacritty reports TERM=alacritty. This requires an updated terminfo/termcap database that
Out of the box on other platforms, alacritty reports TERM=alacritty. This requires an updated terminfo/termcap database that contains an entry for alacritty. When I try to ssh into a FreeBSD machine using a default configuration of alacritty on my macos system, it reports this in my motd(5):

No entry for terminal type "alacritty";
using dumb terminal settings.

Makes sense, thanks! You should put that (or something more terse) in the commit message.

[svmhdvn]

Thanks! Added more info to the commit message.

[concussious]

Please do not push rebases. Once someone has approved it, we have to review it again and it is very difficult to see what has changed.

[svmhdvn]

On April 12, 2025 6:16:58 p.m. UTC, Alexander Ziaee ***@***.***> wrote: concussious left a comment (freebsd/freebsd-src#1638) Please do not push rebases. Once someone has approved it, we have to review it again and it is very difficult to see what has changed. -- Reply to this email directly or view it on GitHub: #1638 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

Got it thanks! Won't push in the future.

[bsdimp]

Actually, rebase pushes are fine... though we prefer that you only push a rebase when you had to do something to fix a conflict. If it's clear the rebase is the same as before, though it's not a big deal. When you do push a rebase to fix a conflict, it's good to add a note explaining the fix...

We're happy you are contributing and can be flexible so kong as that flexibility doesn't cost us much time.

[concussious]

Yes, I hope I didn't sound mean or grumpy, just trying to give helpful advice; I definitely wasn't mad/ didn't want to give any incorrect impression.

[svmhdvn]

Makes sense! Github's interface makes an unnecessary notice upon a rebase when the actual patch contents don't effectively change, so I do prefer the older send-email patch based workflow (or the similar bugzilla workflow) for this reason. Patches stay static until there's a necessity for rebase.

I just had some bad automation in my local scripts that unnecessarily pushed to all my remotes too many times. I'll fix that locally and only push if the patch content changes.

[bapt]

merged thanks