Conversation
Some operating systems, such as FreeBSD, are termcap-only; they do not have terminfo at all. unibi_from_term(), and hence unibi_from_env(), now fall back to a built-in database of terminfo records for some of the more popular modern terminal (emulator) types if no external database file can be found/loaded.
I wouldn't worry too much about that in the longer term. As I've repeatedly explained to everyone involved, Any fix being considered for now is at most a temporary workaround until that time comes. I wouldn't spend too long worrying about how to fix it in its current state. |
|
Wouldn't it make more sense to support termcap directly? |
4 participants
On termcap-only systems — such as FreeBSD and its derivatives TrueOS, DragonFly BSD, and so forth — Unibilium does not work. This makes the lives of things that use Unibilium rather hard.
Neovim is in the process of gaining a workaround that loads up built-in terminfo entries if Unibilium fails:
But this does not work for other libraries that Neovim uses such as libtermkey, which themselves directly call Unibilium internally and do not gain the benefit of Neovim's internal database layered on top of Unibilium. On FreeBSD et al., Neovim's keyboard input subsystem thus falls back to using its non-terminfo hardwired sort-of-xterm-ish input driver.
This shifts the built-in terminfo entries down into Unibilium itself.
There's no compile-time switch for turning these off, because there is not much in the way of compile-time switches in Unibilium, and I was not sure how, or even whether, you want to arrange such a switch. Such a switch is easy enough to do.
A slight difference from Neovim is that there's no default fallback to
ansi. Neovim can afford an ANSI-conformant-at-minimum assumption; since it cannot reasonably be expected to work with a terminal type that lacks all cursor addressibility. Unibilium cannot.