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 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: > > 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.