11:31 <ovf> i might need a little help with my reading comprehension of the vt state machine: when i press f1, foot sends me ^[OP (aka 1b 4f 50). according to both vt100.net's diagram and vt.c, this is something like esc(O) print(P) which doesn't seem right. do the terminal->application communications use a different protocol, after all?

12:07 <krikakruka> hey friends! is there a way to disable all colors/styling in foot? i used to have some success with 'TERM=xterm-mono foot' but i dont have that terminfo in my distro any more

12:08 <krikakruka> TERM=xterm-old foot doesn't do the trick either

12:13 <rcf> krikakruka: do you have ansi-mono? That might work in a pinch.

12:26 <rcf> krikakruka: or, actually, you can cheat and use TERM=foot+base

12:56 <dnkl> ovf: ah, yes... I'd say all query replies and key codes are CSIs or DCSs, and thus do follow the same protocol. F1-F4 are the exception (along with the cursor keys and home/end/pgup/pgdown when they're in "application mode")

12:58 <dnkl> if you're only parsing terminal replies, and key codes, "print" isn't really a thing, since it'll never send plain text. that should make it fairly easy to special case these keys

13:32 <krikakruka> rcf: thanks, but no luck using foot+base, still colors/styling. i don't have ansi-mono terminfo either

13:33 <rcf> krikakruka: note that applications don't always respect TERM anyway.

13:33 <krikakruka> i've managed to turn it off most places, for example with t_Co=0 in vimrc, but some programs dont give me the choice

13:33 <krikakruka> yeah

13:34 <krikakruka> oh well

13:34 <rcf> A lot of those are just blindly putting out ANSI sequences without regard for anything else.

13:34 <rcf> A lot of shell prompt customizations do this, for example.

13:37 <krikakruka> i should reach out to the developers and ask. im using 'offpunk' a lot and would love to skip the colors

13:38 <krikakruka> i get that people like some color in their terminals though

13:41 <rcf> Based on https://git.sr.ht/~lioploum/offpunk/tree/master/item/ansicat.py that is exactly what they are doing.

13:41 <rcf> However, https://git.sr.ht/~lioploum/offpunk/tree/master/item/offthemes.py hints at the possibility to creatively avoid colors

13:44 <dnkl> krikakruka: if you mean "TERM=whatever foot" literally, that won't ever work since it'll be overwritten by foot. You need to set it in foot.ini

13:44 <krikakruka> rcf: thanks! that helps a lot

13:44 <krikakruka> dnkl: yeah i set it in foot.ini, but still colors

13:45 <dnkl> some of the applications that don't respect TERM do respect NO_COLOR

13:45 <krikakruka> i've set NO_COLOR also

13:45 <rcf> Unfortunately offpunk isn't one of them

13:45 <dnkl> I'd definitely ask them to consider supporting it

13:46 <krikakruka> good idea

13:47 <krikakruka> it seems like i should be able to turn it off in offpunk by setting the 'theme' command correctly. somehow i missed that one

13:48 <krikakruka> offpunk is really good

13:54 <krikakruka> nice, it worked. 'theme link white, theme window_title white, theme title white' and so on in offpunkrc did the trick

14:19 <ovf> dnkl: thank you! i think i massively overthought this by starting from the full vt state machine instead of looking at what i can actually get

15:06 <ovf> dnkl: am i right that i still want my function to be total, i.e. it should be ready to receive any byte sequence from the terminal, as one can just type any control sequence directly? despite that the terminal itself would only send me csi/dsc

15:25 <dnkl> ovf: well... I lied a bit... unless you enable e.g. the advanced modes of the kitty keyboard protocol, you do have to handle plain ASCII, as that's how the terminal sends key presses for e.g. A-Z.

15:26 <dnkl> you do *not* have to worry about escape sequences typed by the user - they are received and parsed by the terminal. All escapes you receive will be from the terminal itself

15:27 <dnkl> of course, you also have to deal with escape, 0x1b, since it can _either_ be the start of an escape, or the ESC key. This is one of the major reasons why the extended keyboard modes are being adopted by both shells and editors

15:29 <dnkl> if you do need to handle legacy input, you will have to special case at least the ESC key and F1-F4. I still think using a VT parser is the way to go though

15:46 <ovf> dnkl: thanks! apropos nothing, i'm curious what kind of perf difference are you seeing from pgo?

16:04 <dnkl> recently, not much of a difference at all

16:06 <dnkl> don't know if GCC has gotten worse at pgo, or better at non-pgo. or if we've managed to tag enough branches etc with hints for it to improve non-pgo performance

16:08 <dnkl> the pgo:d binary is smaller in size however

16:26 <ovf> interesting, thanks. is clang that much worse than gcc at compiling that state machine (i suppose that's where you are seeing any difference from pgo)

16:41 <dnkl> i haven't benched any clang builds at all in a long time, I'm afraid

18:01 <rcf> ovf: out of curiosity I did run vtebench on both clang and gcc builds, and the clang results were actually slightly better (though not enough to really notice).

18:44 <ovf> rcf: thanks!

19:44 <ovf> just for the record, the fact that the terminal won't pass me any escape sequences from user input is great news, although apparently not yet heard of in the ghostty-land