<cbb>
it seems like requiring extra steps to install the terminfo entries might trip some people up
<cbb>
it's probably what packagers want anyway
<cbb>
but some people building from source might not know much about terminfo
<cbb>
I wonder if it'd make installation less error prone to install terminfo files to /usr/share/foot/terminfo by default
<dnkl>
cbb: I guess we could restore -Dterminfo. Then packagers would have to rm the terminfo files from the foot package, but I guess they can be counted on getting that right
<cbb>
dnkl: yeah that's what I was thinking
<cbb>
making things as smooth as possible for first time compilers seems like the best default
<sterni>
this whole situation sounds like quite the mess
<sterni>
the consequence of the proposed approach is that the experience will be decreased via ssh though
<sterni>
nix can deal with path collision in packages, so I'm contemplating to just increase foot's priority in the future so it overrides ncurses' terminfo if installed
<dnkl>
sterni: how would it decrease?
<sterni>
well the remote application wouldn't know about certain capabilities right? since they'd have the ncurses terminfo?
<dnkl>
sterni: only if foots own terminfo hasn't been installed. That's better than today where all you get is a "no such terminal", at best, and a broken shell
<sterni>
dnkl: yeah, but foot can't adjust the TERMINFO_DIRS for a remote system, right? so installing foot's terminfo in a non-standard location won't work for that usecase
<dnkl>
sterni: correct, the assumption is all distros use the same custom location.
<dnkl>
Generally, we're opening up for subtle issues
<dnkl>
People thinking they use "our" terminfo when they are in fact using ncurses
<dnkl>
Well, perhaps we should simply rename it instead. But to what? "The-real-foot"?
<dnkl>
I.e different name, but installed to ncurses default location
<dnkl>
Then it'd be up to the users to choose which version to use.
<sterni>
that won't work when ssh-ing into a remote system with the ncurses one installed though?
<dnkl>
sterni: exactly. We'd be back basically where we are today; either make sure our terminfo is installed on the remote, or override TERM when ssh:ing.
<dnkl>
Or always use ncurses' limited version. Including locally
<sterni>
:|
<dnkl>
Yeah...
<cbb>
every time something like this comes up...
<cbb>
I'm reminded that terminfo is basically utter junk
<cbb>
and it'd make far more sense to have a purely Boolean database of capabilities
<cbb>
that would be small enough to fit directly in an env var
<cbb>
there's no excuse for e.g. terminals that don't support the core of ECMA-48, so that could be considered a baseline
<sterni>
what is the core of ECMA-48 though? :D
<dnkl>
*sigh*. Yup... As for prior art, we have kitty that uses a custom terminfo location, and rxvt that uses a different name for its terminfo
<testuser[m]>
is it not possible to tell tdickey to just not include terminfo for a term :p
<cbb>
testuser[m]: I was thinking that
<cbb>
but there are probably more upsides than downsides
<cbb>
to having a terminfo entry in upstream ncurses
<sterni>
ideally we could just upstream whatever into foot's ncurses terminfo
<sterni>
but even then the release cycle may be too slow
<dnkl>
sterni: the problem is many non-standard capabilities are rejected
<dnkl>
We have a number of capabilities used by tmux that I'd like to keep
<sterni>
dnkl: I don't quite see why ncurses would do this tbh?
<sterni>
unfortunately non-standard capabilities are a fact of life
<cbb>
there's a chance we might be able to convince Dickey to allow Tc/setrgbf/setrgbb
<cbb>
there's an X/Open standard for curses
<cbb>
and a lot of stuff in ncurses isn't part of it
<cbb>
so depending on how you define "non-standard", ncurses already contains a bunch of non-standard stuff
<cbb>
just stuff that Dickey happens to agree with
<ericonr>
apparently arch and alpine defer to ncurses databases directly
elshize has joined #foot
<dnkl>
cbb: what did you have in mind? Ask them to ask Dickey to include the caps?
<cbb>
no, after reading the linky ou just posted, I've changed my mind about that ;)
<cbb>
I meant adding an alternative way of detecting true color support to tmux itself
<dnkl>
cbb: ah :)
<cbb>
in theory, they could use $COLORTERM
<cbb>
although perhaps they don't like the fact that it can be inherited across forks
<dnkl>
Assume we stop shipping our own terminfo. What would happen? Worst case scenario?
<ericonr>
how so? tmux has full control over the environment it exports to children
<cbb>
dnkl: worst case in tmux is you have to go back to use terminal-overrides again
<dnkl>
We get me colors-not-working-in-tmux questions?
<cbb>
and without it true color won't work
<ericonr>
and things will start behaving weirdly for that one person who didn't install ncurses databases :p
<dnkl>
ericonr: or is stuck on an old version but compiled foot from spruces
<dnkl>
Sources
* dnkl
is on the phone
<ericonr>
right, that too
<ericonr>
I think only sabotage and oasis are using netbsd-curses, so they don't even have ncurses as packages
<ericonr>
but any users of those can figure things out :p
<dnkl>
I hate this
<dnkl>
I do think it makes sense to continue shipping our own terminfo
<dnkl>
At least for the time being
<dnkl>
So, what's the least bad? Renaming it is easy, without surprises, and makes it very explicit. But might make a transition back to 'foot' (if we decide to rely on the ncurses version) more difficult?
<cbb>
The least bad is supplanting ncurses entirely ;)
<elshize>
hi yall, I can't find it but thought i'd ask anyway: is there a base16 color theme repo for foot? (such as https://github.com/aarowill/base16-alacritty for alacritty)
<elshize>
I'm thinking of creating one, but want to check first
<dnkl>
So, I'm not really hearing any string arguments for, or against, either option. Then I'll continue with the "custom install location" option, since that work is already half way
<dnkl>
elshize: i think there is. Give me a minute to search the issues
<elshize>
dnkl: thanks! I see that adding to list wasn't merged, which explains why I couldn't find it there...
<cbb>
dnkl: it's kind of hard to hold all the upsides/downsides in my head at once
st3r4g has joined #foot
<cbb>
but the custom install location one does seem like a good candidate for "least bad"
<dnkl>
cbb: I'm 100% sure we're missing/forgetting use cases. But I take it that's true for both options, so it evens out :D
<cbb>
yeah, probably
<cbb>
I'll ask the tmux developers about using $COLORTERM (or something else) in addition to Tc/terminal-overrides
<cbb>
If tmux does that it's likely neovim will too and then the only remaining issue is Sync
<cbb>
to be honest, I think Sync is a lesser issue, because anything that uses it probably isn't using the curses API
<cbb>
ericonr: I missed what you said earlier about control over the environment
<cbb>
but I was referring to tmux's environment when it checks $TERM (and hypothetically $COLORTERM)
<cbb>
you can launch a terminal that doesn't set COLORTERM from what that does, which then starts tmux
<cbb>
and the variable will be inherited from the "wrong" one
<cbb>
from one that does*
<cbb>
it's not a problem with TERM, because *every* terminal sets it
<cbb>
imo, not a big deal, but it may be why tmux opted to not use COLORTERM as a source of info
elshize has quit [Quit: WeeChat 3.2]
elshize has joined #foot
<ericonr>
cbb: ah ok, thanks for explaining
elshize has quit [Quit: WeeChat 3.2]
yyp has quit [Remote host closed the connection]
yyp has joined #foot
<dnkl>
cbb: I've updated the PR, and added back -Dterminfo.
cbb has quit [Ping timeout: 256 seconds]
cbb has joined #foot
cbb has quit [Client Quit]
cbb has joined #foot
<cbb>
dnkl: nice one, I'll take a closer look at the patch in a while
<dnkl>
cbb: lots of documentation changes that could use some proof reading ;)
<dnkl>
(and thanks)
cbb has quit [Ping timeout: 256 seconds]
cbb has joined #foot
<Arnavion>
(The PR description still says >meson no longer builds or installs the terminfo files. )
<dnkl>
Arnavion: thanks, will update!
<Arnavion>
The situation is a bit unfortunate though. On OpenSUSE the kitty package does *not* put a copy under lib(exec)dir like you say the Arch package does, so I think foot would be the first in the repo to do that
<Arnavion>
It's not a problem, just unfortunate
veiviser has quit [Remote host closed the connection]
<dnkl>
Arnavion: I don't think it's *just* an Arch packaging thing; Kitty sets the TERMINFO environment variable, pointing to the custom terminfo. This requires explicit support from Kitty itself
<dnkl>
But sure, I'm not happy with any of this
veiviser has joined #foot
veiviser has quit [Remote host closed the connection]
<Arnavion>
I'm saying the OpenSUSE package for kitty doesn't install any extra terminfos, just $datadir/terminfo/k/xterm-kitty
veiviser has joined #foot
veiviser has quit [Remote host closed the connection]
veiviser has joined #foot
<dnkl>
Arnavion: understood. That _is_ the extra terminfo. Ncurses version is called 'kitty'
<Arnavion>
>Kitty also installs its terminfo to a custom location (/usr/lib/kitty/terminfo on Arch).
<dnkl>
I.e they _can_ co-exist
<dnkl>
But kitty has explicit support for having it elsewhere
<dnkl>
Renaming 'foot' is an option. But it has disadvantages too
<dnkl>
How should users know which one to use?
<Arnavion>
Yes, I already understood all of that. I'm not sure you're getting my point
<dnkl>
I guess not. What is your point?
<Arnavion>
You said Kitty on Arch installs /usr/lib/kitty/terminfo. I'm saying Kitty on OS does not. foot on OS would be the first of its kind to do such a thing
<dnkl>
Arnavion: yes, but is that a problem? Would it be better to provide a differently named terminfo, installed in the standard location?
<Arnavion>
<Arnavion> It's not a problem, just unfortunate
<dnkl>
Well, terminfo is unfortunate ;)
<Arnavion>
Also depending on when the next ncurses releases, I guess the packages will be in conflict, but meh
<dnkl>
That's why I'm trying to prioritize this, so that we can avoid that
veiviser has quit [Remote host closed the connection]
veiviser has joined #foot
<Arnavion>
Heh, I was thinking of changing it to put it under $datadir/foot next to foot.ini, then I realized that's already what you're doing, so :+1:
<sosodank>
i hope the name doesn't change; i enjoy being reminded of the foot clan
ynakao has quit [Quit: WeeChat 3.2]
ynakao has joined #foot
<sosodank>
fwiw i've always hoped that all the terminfo database entries would be distributed with libterminfo, and terminal authors would push their changes to terminfo promptly