Please do not hardcode the terminfo database

[christianparpart]

the terminfo database seems hardcoded and therefore less likely correct

Specifications

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

We have received a bug report today at contour-terminal/contour#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 👍) 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.

[niten94]

The commit where terminfo entries in the system database are used instead of builtin entries when available has been reverted, so I think this issue should be reopened. I read in a comment that the bug was discussed in Discord so I joined the server and tried reading old messages to know details, but I can understand why the situation with terminfo in micro looks bad.

Micro seems to crash with an exit status of 0 (probably bug with Go) without restoring the terminal state properly because the size of the array created in this line is multiplied with a negative height value once:
https://github.com/zyedidia/tcell/blob/969958742a553232cbae8fcc291907a98e57b860/cell.go#L149

Terminfo files are loaded using the output of running infocmp upstream but xo/terminfo (Go module, like library) is used instead in the tcell fork. It is written in term(5) man page of ncurses that absent integer capabilities are set as -1 in terminfo files, but the value returned is not modified when xo/terminfo is used.

Absent capabilities may be expected to be remain initialized as 0 in the source code upstream, because it is written in the man page of the ncurses version of infocmp(1) that they are not printed. The value is not set to 0 in the fork even if negative, so the amount of lines remains as -1.

I do not know the reason much but Go programs do not usually use FFI, so a library written in another language cannot be used to read terminfo entries. I think adding a new function to the tcell fork and an option to micro can be done if using builtin entries by default is preferred for some reason.