07:48 <runxiyu_> There are some font sizes where underlines disappear. I'm using the DejaVu Sans Mono fonts and I don't really want to change fonts. Any ideas on how to fix?

07:54 <dnkl> runxiyu_: I can't reproduce. This used to be an issue way back before foot 1.8. I assume you're not using an ancient version of foot?

07:54 <runxiyu_> foot version: 1.17.2 -pgo +ime +graphemes -assertions

07:54 <runxiyu_> Running on Asahi Linux Apple M1 with Sway, no fractional scaling, dpi-aware=0

07:55 <dnkl> runxiyu_: no idea then. Doesn't happen here, with Dejavu as primary font

07:56 <runxiyu_> hmm

07:56 <dnkl> check foot -d info output, and see if anything stands out

07:57 <dnkl> or if everything appears ok, give me the font and cell width/height lines (from the log output) for the sizes where it happens

07:57 <runxiyu_> https://paste.sr.ht/~runxiyu/b16deb0a7cb909b0249f44caf9790db337b9014d

07:57 <runxiyu_> info: terminal.c:813: cell width=7, height=14

07:58 <runxiyu_> info: fcft.c:848: /usr/share/fonts/dejavu-sans-mono-fonts/DejaVuSansMono.ttf ; from Asahi repos

07:59 <dnkl> at that pixelsize I get a cell height of 15

07:59 <dnkl> that could explain why the underline isn't visible for you

08:00 <dnkl> but the cell width/height is based on the font metrics, which are set by freetype, not foot or fcft

08:00 <runxiyu_> ah okay

08:01 <runxiyu_> I don't think I did anything weird to freetype, hm

08:01 <runxiyu_> https://git.runxiyu.org/runxiyu/uconf.git/tree/.config/foot/foot.ini#n17

08:01 <runxiyu_> Oh I'm using default :size=20 line-height=24

08:01 <dnkl> ah, if you explicitly set the line-height, then yes, that could cause issues

08:02 <dnkl> (when you zoom in/out)

08:03 <dnkl> when you set a custom line-height, it is scaled by the same amount as the font, when you resize it. But for small font sizes (and 12px is small), rounding errors can and do occur

08:03 <runxiyu_> ahh

08:03 <runxiyu_> I'll stop using line-height for now and perhaps modify the font to be a bit taller

08:04 <runxiyu_> Alright this feels so much better

08:08 <dnkl> we should add a warning (in the man page) to all the options that override font metrics...

08:11 <runxiyu_> agreed

10:08 <krobelus> dnkl: I think for fish, simple CSI push/pop won't work; if I run "fish1 -> ssh -> fish2" and the connection drops, then fish2 has no chance to pop. So the flag stack will be corrupted. It seems better to always set the flags directly. I'm not sure if there is a use case for "nesting" where the push/pop semantics are really necessary. The shell wants to reset all flags whenever it surrenders or

10:08 <krobelus> acquires control of the terminal (before or after running an external program), it seems like other programs can do the same. Unfortunately there is still a problem for "bash -> ssh -> fish", I guess ssh should clean up (actually that might work better with the stack, if we allow getting stack size and truncating it)

10:38 <dnkl> krobelus: I think for both XTPUSHCOLORS, and the kitty kbd, what you really want is: push, request current stack slot/level from terminal, do your stuff, then explicitly restore to the slot before your push

10:38 <dnkl> don't remember; can you query the current stack depth with the kitty kbd?

10:42 <krobelus> dnkl: the problem is that "do your stuff" is a blocking "read(stdin)", and if that gets interrupted by a connection drop I can't clean up

10:43 <dnkl> ah, right. Correct, for all this to work, you have to have something locally that also restores/cleans up

10:43 <krobelus> I don't think there's a way to query stack depth yet, but that should be easy to add. Probably that's the way to detect and fix leaked pushes

10:43 <krobelus> I wonder if SSH is open to cleaning up unconditionally

10:44 <krobelus> I guess there is no reason to ever want a push event to outlive ssh

10:45 <cbb> dropped connections leaving the terminal in a weird state isn't really specific to this case

10:46 <cbb> it can leave private modes set etc.

10:48 <krobelus> cbb: right, maybe we can clean up all of these

10:49 <krobelus> unfortunately it's a leaky abstraction when used with tmux for example. If I reconnect and do "tmux a", the program running inside of tmux will have no idea that it needs to reinitialize terminal modes

14:33 <dnkl> rockorager: just an FYI; I

14:33 <dnkl> I'm not merging the resize notifications PR until I hear from you

14:34 <dnkl> (i.e. waiting for some signs the spec has been finalized/agreed upon, and hopefully picked up by other terminals/applications)

14:37 <rockorager> dnkl: ack

19:48 <delthas> dnkl: rockorager: is there anything an app should do with light/dark mode? like, it a terminal switches to dark mode, it will also change the mapping of its colors, right? so i wouldn't need to do anything? whats the use case for the spec?

21:41 <rockorager> delthas: I think you might be talking about a different spec? dnkl is referring to the in-band resize spec

21:42 <delthas> yes, unrelated to previous messages

21:48 <rockorager> Ah. the light dark mode use case (mode 2031) is for rgb color schemes mostly

21:50 <rockorager> so if you are neovim with a heavily rgb based theme, changing your DE to light or dark will flow all the way through