Please do not hardcode the terminfo database

[christianparpart]

the terminfo database seems hardcoded and therefore less likely correct

Specifications

Commit hash: micro 3cbbba534c6b2d0f5ab938679ca442d13c164eba OS: Fedora 36 Terminal: Contour (latest master)

We have received a bug report today at https://github.com/contour-terminal/contour/issues/796 because micro would not run in Contour terminal emulator. I figured that micro isn't even doing much and simply leaves the terminal in a real bad state, i.e. hidden cursor in alt screen. So from user's PoV, running reset will fix the mess. But there are a couple of issues here.

• Why did this happen in the first place? Because our terminal does not expose lines#24 in the static database, so I got told that this is queried
• Whatever problem happens during TUI initialization, the user must not suffer from a screen in a bad state. It would be best , generally speaking, if micro upon exit restores the terminal state, at least showing cursor and going back to primary screen again.
• micro seems to depend on a forked tcell library, which seems to have a hardcoded copy of a terminfo database at build time. It's a very long time ago when I was coded in Go, so I might misunderstand here something. But to my understanding, micro queries information that it gets from tcell, and tcell has that information from its "during build-time generated .go files", which is a copy of the local terminfo files, as parsed from the output of infocmp. To me this feels like it can go very well wrong. Suppose you have a user having a somewhat newer version of some existing terminal tcell has imported the terminfo db for. But the contents has changed. Now, that user will however always get outdated, potentially stale invalid data as terminfo responses through tcell, because it's using the terminfo information from the .go files, and not from the up-to-date terminfo file. To me, purely personally, this sounds bad by design. And I would love to encourage you to change the design to parse the actual terminfo files simply at process startup for only that terminal that is being configured via TERM env var. Alternatively, XTGETTCAP VT sequence should definitely be at help, which is supported on many terminals, too.

WRT lines numeric capability, we're now having a PR on our side to provide that via terminfo file. However, I think modern applications must not depend on that capability at all. There are plenty of other ways to definitely get a correct value (tcgetattr(), XTWINOPS). What do you think?

Have a nice day/night. ;)

[zyedidia]

I think the static database is sort of left-over from before tcell had support for dynamic terminfo parsing, and now remains as a "performance improvement," with the dynamic parsing as a fallback. Maybe it should in fact be the other way around. I'll look into fixing this, thanks for bringing this up.

[JoeKar]

I was triggered by #3101 (@niten94 :+1:) that this issue exist and would like to do the change. As already mentioned in zyedidia/tcell#26 it would be nice if not fork is necessary at all any longer, but I assume this does not happen in the next time...

Anyway, switching the order doesn't seem to be a big deal, but it will take effect earliest after the dependency reference will be updated.