hmht_ has quit [Remote host closed the connection]
boomboxnation has quit [Ping timeout: 240 seconds]
boomboxnation has joined #foot
hmht_ has joined #foot
sentriz has quit [Remote host closed the connection]
sentriz has joined #foot
lbia has quit [Ping timeout: 256 seconds]
jts has joined #foot
Biolunar has quit [Ping timeout: 256 seconds]
Biolunar has joined #foot
lbia has joined #foot
<rockorager>
dnkl: do you have any opinions on a private mode which subscribes an application to receive automatic window size updates (CSI 8 and 4...char and pixel reports)?
<rockorager>
I recently did some work on the win32 console api and having window size events in the same stream as input is just...so nice
jts has quit [Ping timeout: 260 seconds]
hmht_ has quit [Remote host closed the connection]
<dnkl>
rockorager: in general, I don't like adding new ways to do things, just because it's "nice"
<dnkl>
but in this case, the current system is racy
<dnkl>
(lots of bug reports for "incorrect" window sizes in vim, neovim, shells etc etc at startup, due to multiple, quick resizes)
<rockorager>
Yes, there are some necessary pains to handle size changes via SIGWINCH app developers must take
<dnkl>
so, if the new escapes are designed such that the current window size is always reported directly after enabling a subscription, then that would improve the current situation enough that I think it would be worth to add
<rockorager>
As in - when you enable the mode, you get an immediate size notification and also receive sequences when the size changes?
<dnkl>
yes
<rockorager>
An implicit CSI 14 + CSI 18 on enable, yeah
<dnkl>
to make it impossible to miss any size changes
<rockorager>
I like that
<rockorager>
I will check with gpanders on if he would support in neovim too
<dnkl>
rockorager: follow up question: an interactive resize could generate *a lot* of resize events. Should the spec. for the new escapes say anything about that?
<dnkl>
for example, foot, *by default*, but not necessarily, throttles SIGWINCHes
<rockorager>
I don't think the spec should dictate how often they are sent
<rockorager>
Either side could choose to throttle or debounce
<dnkl>
that makes things easier
<rockorager>
debounce isn't the right word...
<dnkl>
get what you mean :)
<dnkl>
so in foot, I'd couple the new escape with my SIGWINCHes
<dnkl>
they may be throttled, or not, depending on user conf
<rockorager>
I think I would want to have two modes actually. One to receive pixel updates and one to receive cell updates
<rockorager>
So applications could choose one or both
<rockorager>
Yeah - I am guessing for most terminals this would be extremely easy to implement
<rockorager>
And it's already queryable since it would be a private mode
<dnkl>
agreed, the modes should be separate
<rockorager>
We really need some sort of terminal-working group ;)
<dnkl>
with as many people as possible involved, to get as much feedback as possible...
<dnkl>
rockorager: is there any ticket or similar I can follow?
<rockorager>
Not yet - I'll write something up later today
<rockorager>
And ping you with a link
<dnkl>
toast: did some work on the dotted underlines. Still visibly uneven with small font sizes, but better than before, imho
<toast>
will rebuild this weekend and reach back out :)
<toast>
ah heya rockorager
<rockorager>
o/
<dnkl>
rockorager: btw, for pixels, are you thinking of cell size, text area size or window size?
<rockorager>
I think … text area, I assume that’s what is reported via SIGWINCH?
<rockorager>
erg, ioctl
<rockorager>
I guess conceivably any of those could be a mode
<dnkl>
rockorager: we'll definitely need text-area, for sixels. That makes cell dimensions unnecessary, since it can be derived from the text area
<dnkl>
on Wayland, window size is mostly useless I think. There isn't really anything you can do with it