[bug#53257] [PATCH] gnu: foot: expose terminfo dirs via native-search-paths

[Florian <florhizome@posteo.net>]

Hi Maxime,
I understand this kinda differently so far:
We want to expose the path where foot installs it's terminfo via
TERMINFO_DIRS, so that
every program running in that Terminal can look it up. foot without the
patch emits the following env vars inside it's process:

~ $ env | grep TERM
COLORTERM=truecolor
TERM=foot-direct

(i configured it to use foot-direct, and not foot-xterm, which is the
other terminfo it installs, bc that should give me more colors in emacs)
now what happens is that neither foot nor programs running from it seem
to know what foot-direct is.
As I tried to describe, foot renders problematic stuff, whenever the
text it displays reaches it's borders, simply a long line does it, but
also looking up manpages (i would get a

WARNING: terminal is not fully functional
Press RETRUN to continue

when typing "git send-email --help" f.e.

Comparing to kitty: Running in kitty:

COLORTERM=truecolor
TERMINFO=/gnu/store/zhmzdniycjykb6igrx4avs9vsn4ngk5q-kitty-0.20.3/lib/kitty/terminfo
TERM=xterm-kitty

So, kitty exposes the exact path to it's terminfo files within it's
process. so, we are fine, most of the time. But when i try to edit a
file with elevated right's, emacs complains:

~ $ sudo emacs -nw .config/guix/home.scm 
Passwort: 
emacs: Terminal type xterm-kitty is not defined.
If that is not the actual type of terminal you have,
use the Bourne shell command 'TERM=...; export TERM' (C-shell:
'setenv TERM ...') to specify the correct type.  It may be necessary
to do 'unset TERMINFO' (C-shell: 'unsetenv TERMINFO') as well.

an interesting example with guix shell and nano:

~ $ guix shell nano -- nano ./.config/guix/home.scm
Folgende Ableitung wird erstellt:
   /gnu/store/azcaj49div66k43afiiiq6njsjk8s5iv-profile.drv

Zertifikatsbündel der Zertifikatsautoritäten wird erstellt …
Liste der Emacs-Unterverzeichnisse wird erzeugt …
Schriftartenverzeichnis wird erstellt …
Verzeichnis von Info-Handbüchern wird erstellt …
Profil mit 1 Paket wird erstellt …
~ $ guix shell nano --pure -- nano ./.config/guix/home.scm
Error opening terminal: xterm-kitty.

(so, the first one worked, the second not.)
kitty works as long as i "preserve context" i would say, without
understanding in depth what happens.

So, to me it seems setting search-paths should make sense whenever you
want to expose a path in the store directory of a certain package, but
you cannot be sure to which package (otherwise, a wrapper would make
sense, and that's where your definiton of producer and consumer applies
better i think as it would be a much directer and clearer definition. ). In gnu guix we would want to take advantage of that rather more
then less i think, but it's poorly documented.
By my understanding, if emacs installs a terminfo file, yes, we could
set it's search-path field similar to alacritty. But it most definitely
makes sense for any terminal emulator that defines an own TERMINFO
variable and ships a terminfo file with that (and so a TERMINFO_DIR that
we want to expose to the environment). 

Now what i don't understand is when I would set search-paths, but not
native-search-paths --- as i said, in this example search-paths would
make more sense to me, if I understood the two fields right. 

Greetings,
Florian.

Maxime Devos <maximedevos@telenet.be> writes:

> florhizome schreef op vr 14-01-2022 om 14:02 [+0000]:
>> Hi all,
>> I noticed foot did not behave normally whenever content would overflow it's current dimensions.
>> when I installed alacritty in the same profile, this was fixed. Turned out, alacritty's
>> declaration has a native-search-path field entry that fixed foot! Why not just search-paths,
>> I can't tell. This might apply to further terminal emulators (kitty had problems starting emacs
>> in some contexts for me but I would need to test that more), but for now, just foot! 
>> 
>
> Canonically, search path are set in ‘consumers’, not ‘producers’
> (though setting it in ‘producers’ sometimes works).  Here,
> ‘consumer’ = ncurses, maybe screen (why doesn't screen have a native-
> search-paths?  An oversight?), and ‘producer’ = some terminal emulator.
>
> What application were you running in foot that leaded to an overrun?
> Maybe we should add TERMINFO_DIRS to the native-search-paths of the
> application.  Basically all applications using ncurses need it, I
> think?
>
> The following seems relevant:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22138>
> though personally that doesn't seem a bug to me.
>
> Were you running emacs in the terminal?  If so, maybe TERMINFO_DIRS
> need to be added to 'emacs'?
>
> Greetings,
> Maxime.