Co-exist with the foot terminfo in ncurses #671

dnkl commented 2021年08月05日 19:47:42 +02:00

The next release of ncurses will ship a version of foot's terminfo. This was added by Dickey himself, without (as far as I know) anyone requesting it.

There are a couple of issues with it, described in detail in #670.

The major issue I have with it, is that it lacks a number of non-standard capabilities, that I don't want to drop. But that are very unlikely to be added to ncurses.

As such, I'd like to keep distributing our own terminfo. How do we do that, without conflicting with the ncurses provided version?

Best idea I have so far is we install our terminfo in a non-standard location (/usr/share/foot/terminfo? /usr/lib/foot/terminfo?), and append that path to TERMINFO_DIRS before we exec the client application.

The next release of ncurses will ship a version of foot's terminfo. This was added by Dickey himself, without (as far as I know) anyone requesting it. There are a couple of issues with it, described in detail in https://codeberg.org/dnkl/foot/issues/670. The major issue I have with it, is that it lacks a number of non-standard capabilities, that I don't want to drop. But that are _very_ unlikely to be added to ncurses. As such, I'd like to keep distributing our own terminfo. How do we do that, without conflicting with the ncurses provided version? Best idea I have so far is we install our terminfo in a non-standard location (`/usr/share/foot/terminfo`? `/usr/lib/foot/terminfo`?), and **append** that path to `TERMINFO_DIRS` before we exec the client application.

dnkl commented 2021年08月07日 13:12:24 +02:00

So, trying to figure out how to configure this at build time.

We currently have:

• -Dterminfo=disabled|enabled|auto
• -Dterminfo-install-location=<default>|<custom path>|disabled

-Dterminfo controls whether the terminfo files are built, at all. It also controls the default value of TERM.

-Dterminfo-install-location defines the path where the terminfo files are installed, defaulting to ${datadir}/terminfo.

At first, it might seem convinient to use -Dterminfo-install-location and export it in TERMINFO_DIRS if it has been set to a non-default value. However, there's the special value disabled, which means "build the terminfo files, but don't install them". It is meant to be used when packaging foot's terminfo files in a separate package, and removes the need to rm the terminfo files in the foot package.

Perhaps the best option is to remove support for disabled. For the AUR package, this would mean we'd have to revert the following patch:

@@ -46,7 +46,13 @@ build() {
 ;;
 esac
 
- meson --prefix=/usr --buildtype=release --wrap-mode=nodownload -Db_lto=true . build
+ meson \
+ --prefix=/usr \
+ --buildtype=release \
+ --wrap-mode=nodownload \
+ -Db_lto=true \
+ -Dterminfo-install-location=disabled \
+ . build
 
 if [[ ${do_pgo} == yes ]]; then
 find -name "*.gcda" -delete
@@ -96,6 +102,5 @@ check() {
 package() {
 cd foot
 DESTDIR="${pkgdir}/" ninja -C build install
- rm -rf "${pkgdir}/usr/share/terminfo"
 install -Dm 644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
 }

So, trying to figure out how to configure this at build time. We currently have: * `-Dterminfo=disabled|enabled|auto` * `-Dterminfo-install-location=<default>|<custom path>|disabled` `-Dterminfo` controls whether the terminfo files are **built**, at all. It also controls the default value of `TERM`. `-Dterminfo-install-location` defines the path where the terminfo files are installed, defaulting to `${datadir}/terminfo`. At first, it might seem convinient to use `-Dterminfo-install-location` and export it in `TERMINFO_DIRS` if it has been set to a non-default value. However, there's the special value `disabled`, which means "build the terminfo files, but don't install them". It is meant to be used when packaging foot's terminfo files in a separate package, and removes the need to `rm` the terminfo files in the `foot` package. Perhaps the best option is to remove support for `disabled`. For the AUR package, this would mean we'd have to revert the following patch: ```diff @@ -46,7 +46,13 @@ build() { ;; esac - meson --prefix=/usr --buildtype=release --wrap-mode=nodownload -Db_lto=true . build + meson \ + --prefix=/usr \ + --buildtype=release \ + --wrap-mode=nodownload \ + -Db_lto=true \ + -Dterminfo-install-location=disabled \ + . build if [[ ${do_pgo} == yes ]]; then find -name "*.gcda" -delete @@ -96,6 +102,5 @@ check() { package() { cd foot DESTDIR="${pkgdir}/" ninja -C build install - rm -rf "${pkgdir}/usr/share/terminfo" install -Dm 644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } ```

dnkl commented 2021年08月07日 14:46:57 +02:00

I'm tempted to simply stop building the terminfo all together. That is, require users and packagers to build the terminfo files manually.

We could then provide two meson options for foot:

• -Ddefault-terminfo=<name> (defaults to foot)
• -Dcustom-terminfo-install-location=<path>

-Dcustom-terminfo-install-location would only be used to decide if (and to what) TERMINFO_DIRS should be set.

-Ddefault-terminfo sets the default value for the term option in foot.ini. We should also pre-process doc/foot.ini.5.scd (to update the default value).

INSTALL.md would have to be updated, obviously.

I'm tempted to simply stop building the terminfo all together. That is, require users and packagers to build the terminfo files manually. We could then provide two meson options for foot: * `-Ddefault-terminfo=<name>` (defaults to `foot`) * `-Dcustom-terminfo-install-location=<path>` `-Dcustom-terminfo-install-location` would only be used to decide if (and to what) `TERMINFO_DIRS` should be set. `-Ddefault-terminfo` sets the default value for the `term` option in `foot.ini`. We should also pre-process `doc/foot.ini.5.scd` (to update the default value). `INSTALL.md` would have to be updated, obviously.

dnkl commented 2021年08月09日 20:34:48 +02:00

The current plan is to keep building the terminfo definitions in the meson build. By default, that is. We keep the -Dterminfo option, but it no longer controls the default TERM value.

Thus, a distro that manually builds and packages (in a separate package) the terminfo files, could configure the foot build with:

meson -Dterminfo=disabled ...

This will result in a build that uses foot as the default TERM, with our terminfo files installed in ${prefix}/${datadir}/foot/terminfo (e.g. /usr/share/foot/terminfo).

To complete disable "our" terminfo files, and instead rely completely on ncurses', you could do:

meson -Dterminfo=disabled -Dcustom-terminfo-install-location=no

The current plan is to keep building the terminfo definitions in the meson build. By default, that is. We keep the `-Dterminfo` option, but it no longer controls the default `TERM` value. Thus, a distro that manually builds and packages (in a separate package) the terminfo files, could configure the foot build with: ```sh meson -Dterminfo=disabled ... ``` This will result in a build that uses `foot` as the default `TERM`, with our terminfo files installed in `${prefix}/${datadir}/foot/terminfo` (e.g. `/usr/share/foot/terminfo`). To complete disable "our" terminfo files, and instead rely completely on ncurses', you could do: ```sh meson -Dterminfo=disabled -Dcustom-terminfo-install-location=no ```

sv commented 2021年08月15日 15:29:51 +02:00

For what it's worth, some other applications* were unable to peacefully co-exist with the foot's terminfo, but were very happy with term=xterm-256color. I haven't noticed any particular disadvantages to it.

* tmux, weechat, neovim...

For what it's worth, some other applications* were unable to peacefully co-exist with the foot's terminfo, but were very happy with `term=xterm-256color`. I haven't noticed any particular disadvantages to it. <small>* tmux, weechat, neovim...</small>

dnkl commented 2021年08月15日 16:39:31 +02:00

@sv there are several disadvantages. At least when comparing foot's terminfo from 1.8. There are several capabilities in our terminfo that isn't included in xterm256-color, that benefit tmux, and potentially other.

But perhaps more importantly, if ncurses adds new capabilities to xterm-256color, then foot will suddenly start to fail in mysterious ways. This has happened in the past, though that was before foot's time.

FWIW, I run both neovim and weechat daily, with foot's terminfo, without any issues what so ever. AFAIK, tmux works just fine with it as well.

That said, it is certainly possible there were issues with our terminfo in 1.6. Lots have changed since.

@sv there are several disadvantages. At least when comparing foot's terminfo from 1.8. There are several capabilities in our terminfo that isn't included in `xterm256-color`, that benefit tmux, and potentially other. But perhaps more importantly, if ncurses adds new capabilities to `xterm-256color`, then foot will suddenly start to fail in mysterious ways. This **has** happened in the past, though that was before foot's time. FWIW, I run both neovim and weechat daily, with foot's terminfo, without any issues what so ever. AFAIK, tmux works just fine with it as well. That said, it is certainly possible there were issues with our terminfo in 1.6. Lots have changed since.

sv commented 2021年08月16日 01:40:42 +02:00

Shall check if 1.6.X terminfo is interfering with the manually built 1.8.X.

There are several capabilities in our terminfo that isn't included in xterm256-color, that benefit tmux, and potentially other.

Is there a list? Would appreciate at least some brief summary.

Shall check if 1.6.X terminfo is interfering with the manually built 1.8.X. > There are several capabilities in our terminfo that isn't included in xterm256-color, that benefit tmux, and potentially other. Is there a list? Would appreciate at least some brief summary.

dnkl commented 2021年08月16日 07:27:55 +02:00

There's Sync, which informs applications foot can do "Application synchronized updates" (i.e no tearing).

There's Tc, setrgbf and setrgbb which tells tmux the terminal is 24-bit (color) capable. This removes the need to add foot as an override in the tmux config.

Those are the ones I can remember.

Run infocmp -x xterm-256color foot to see the full diff.

There's `Sync`, which informs applications foot can do "Application synchronized updates" (i.e no tearing). There's `Tc`, `setrgbf` and `setrgbb` which tells tmux the terminal is 24-bit (color) capable. This removes the need to add foot as an override in the tmux config. Those are the ones I can remember. Run `infocmp -x xterm-256color foot` to see the full diff.

sv commented 2021年08月25日 14:14:11 +02:00

After running with v1.8.2 foot & terminfo for a week:

• neovim 0.4.4 works fine with all "hacks" removed from ~/.vimrc
• tmux 3.1c works fine with all "hacks" removed from ~/.tmux.conf
• neovim inside of tmux works fine (!) with all hacks removed from both.
• vifm works fine

(drum roll)

• vim 8.2 fails with multiple issues surrounding termguicolors, different cursors, etc.

$ toe
foot 	foot terminal emulator
foot-direct	foot with direct color indexing

After running with v1.8.2 foot & terminfo for a week: - neovim 0.4.4 works fine with all "hacks" removed from `~/.vimrc` - tmux 3.1c works fine with all "hacks" removed from `~/.tmux.conf` - neovim _inside_ of tmux works fine (!) with all hacks removed from both. - vifm works fine (drum roll) - vim 8.2 fails with multiple issues surrounding `termguicolors`, different cursors, etc. ```sh $ toe foot foot terminal emulator foot-direct foot with direct color indexing ```

dnkl commented 2021年08月25日 14:19:22 +02:00

vim 8.2 fails with multiple issues surrounding termguicolors, different cursors, etc.

Are the issues related to moving foot's terminfo to a custom location, or are you comparing with xterm-256color?

Can you show me your config, and give some concrete examples of differences between TERM=foot and TERM=xterm256-color (assuming that's what you're comparing with)?

FWIW, I mostly use neovim, but have a working vim (with TERM=foot). However, I do believe the following is required:

" 24-bit color support
set termguicolors
let &t_8f = "\<Esc>[38:2::%lu:%lu:%lum"
let &t_8b = "\<Esc>[48:2::%lu:%lu:%lum"

I also have:

set ttymouse=sgr
set mouse=a

(but note that I'm not a heavy (neo)vim user - I use Emacs primarily).

> vim 8.2 fails with multiple issues surrounding termguicolors, different cursors, etc. Are the issues related to moving foot's terminfo to a custom location, or are you comparing with xterm-256color? Can you show me your config, and give some concrete examples of differences between `TERM=foot` and `TERM=xterm256-color` (assuming that's what you're comparing with)? FWIW, I mostly use neovim, but have a working vim (with `TERM=foot`). However, I do believe the following is required: ``` " 24-bit color support set termguicolors let &t_8f = "\<Esc>[38:2::%lu:%lu:%lum" let &t_8b = "\<Esc>[48:2::%lu:%lu:%lum" ``` I also have: ``` set ttymouse=sgr set mouse=a ``` (but note that I'm not a heavy (neo)vim user - I use Emacs primarily).

sv commented 2021年08月25日 14:50:51 +02:00

let &t_8f = "\<Esc>[38:2::%lu:%lu:%lum"
let &t_8b = "\<Esc>[48:2::%lu:%lu:%lum"

Yes, these two restore vim.nox from B/W to colour. There are still issues with the cursor shapes (which work "automagically" in neovim) and some highlight groups.

Will respond later with minimal reproducible ~/.vimrc, don't want to waste your time with the whole thing.

``` let &t_8f = "\<Esc>[38:2::%lu:%lu:%lum" let &t_8b = "\<Esc>[48:2::%lu:%lu:%lum" ``` Yes, these two restore `vim.nox` from B/W to colour. There are still issues with the cursor shapes (which work "automagically" in neovim) and some highlight groups. Will respond later with minimal reproducible `~/.vimrc`, don't want to waste your time with the whole thing.