04:36 <Consolatis> dnkl: i am currently playing around a bit more with XTGETTCAP, it seems to not escape "\" (like in the end char of "Ms"), is this intended? And on a related note: is there some flag or string I could look up before actually sending a request to an unsupporting terminal and expecting a reply? (preferably xtgettcap or something similar which would then be "\EP+q%p1%s\E\\" for foot)

04:43 <Consolatis> wait, its actually slightly different, "fsl" isn't encoded at all ( (which actually makes sense as its hex anyway), but "Ms" is encoded

04:44 <Consolatis> sorry, multi line paste..

04:46 <Consolatis> so what i am seeing via xtgettcap is this: fsl: "\x1b\\" (two bytes, not encoded), Ms: "\\E]52;%p1%s;%p2%s\\E\\" (encoded)

05:50 <dnkl> Consolatis: I remember following xterm and kitty here, and the difference is due to one of them containing parameters. Not saying I like it, but didn't want to introduce a different behavior at the time

05:51 <dnkl> re. adding a reminding capability, that would be fine. We should try to sync with kitty though

05:52 <dnkl> the fallback is to emit the XTGETTCAP sequence followed by a DA, and based on the reply figure out if the terminal supports XTGETTCAP or not

05:55 <Consolatis> re fallback: that could work i guess. not as nice as just doing a test -n "$(tput xtgettcap)" but if we can rely on terminals ignoring the sequence + responding to DA that would work as well

05:56 <Consolatis> re parsing: so I guess something like if "%p" in data: data = unescape(data) would do the trick then

05:57 <Consolatis> but that would still mean that "Ms" seems to miss a terminating "\\" (so it has 4 "\" at the end)?

05:58 <Consolatis> well actually 2 not 4, currently only seems to have 1

06:34 <dnkl> Consolatis: I'll check the missing \ as soon as I can

06:35 <Consolatis> dnkl: take your time, I am just playing around with it so far. Thinking about adding a xtgettcap terminfo backend to tcell at one point in the future though

06:39 <dnkl> Consolatis: no worries. It's just that things mentioned here are forgotten if I don't do them soon 😅

06:41 <Consolatis> sounds very familiar :)

06:42 <dnkl> Consolatis: fwiw, here's foot's logic for escaping vs. not when generating the built-in terminfo

06:42 <dnkl> https://codeberg.org/dnkl/foot/src/branch/master/scripts/generate-builtin-terminfo.py#L53-L62

06:42 <dnkl> we only look for '%', rather than '%p'

06:44 <dnkl> and yeah, looks like we're not double-escaping plain \

06:50 <Consolatis> ah, nice one, will mimic that with tcell then. it already has an internal unescape() for infocmp -x output so it only needs to use it when there is an % in the hex decoded value

06:51 <Consolatis> the decision to only escape when containing parameters seems pretty random though

06:51 <Consolatis> as its hex encoded anyway

06:54 <dnkl> I completely agree. I have a few guesses as to why, but in the end it does appear to not have been given enough thought

06:55 <dnkl> we could change this. probably better to do it now, before XTGETTCAP use becomes common. But then we'd be incompatible with at least kitty, and maybe xterm too, depending on which way we go

07:09 <Consolatis> i don't think any one of the two can be used as a complete terminfo replacement though afaiu: xterm only gives keys back and kitty misses bools, also there doesn't seem to be a terminfo name for the query yet. so imho you could totally use a new DSC, remove the parameter encoding, add a new terminfo name for it, define one query -> one response and be the de facto standard for the future which kitty / xterm could adapt to

07:10 <Consolatis> DCS*

07:14 <Consolatis> this protocol would solve not just remote connection issues but also the issue of different versions of the same terminal emulator supporting different features. e.g. using foot but a distro shipped ncurses that omits some features from foot's terminfo

07:18 <Consolatis> not sure how to define the reply format though, guess it could also be a terminfo name using a parameter.. is there some kind of reverse tiparm() to allow applications to automatically parse replies?

07:39 <dnkl> Consolatis: I think this is something worth opening an issue on codeberg.

07:50 <Consolatis> alright, will do soon

08:10 <Consolatis> looks like foot's implementation of xtgettcap is solid, got it running as tcell's only terminfo backend and everything seems fine :)

08:35 <Consolatis> only returns 256 colors + setaf / setab for indexed color instead of direct color though. Not sure how to deal with things like that properly within the xtgettcap framework

08:36 <Consolatis> other than additionally defining setdcf / setdcb that is

08:37 <Consolatis> reusing setaf / setab for direct color might not have been the best decision

08:47 <dnkl> Consolatis: you can look for setrgbb and setrgbf

08:48 <dnkl> they're non-standard (not used in ncurses), but *are* used by (and defined by) tmux

08:49 <dnkl> of course, nothing of what we've discussed here will work for users that use the foot terminfo from ncurses since all these capabilities are "non-standard" and won't be merged upstream

08:50 <dnkl> but, if we start adding more capabilities, used by more applications than tmux, we could change our recommendation to distributions, and say our terminfo is better :)