00:01 <anarcat> ovf: yeah, i used -f because -ff -o throws the output in too many files

05:29 <dnkl> ovf: ah, of course. I never read the stack trace myself, too hard on the phone...

08:03 <dnkl> anarcat: btw, the failed futex calls mentioned in the issue isn't necessarily a problem. A futex call failing with EAGAIN just means the futex value changed *before* the call

08:04 <dnkl> again, smells *a lot* like a thread synchronization issue

12:13 <ovf> dnkl: haha https://github.com/vim/vim/commit/279dd703e16cfa9e5089fb5e7c60b21a0a7debc3 makes vim (with 'set nocompatible') behave weird under foot... and not any other terminal emulator at hand. haven't looked further

12:18 <ovf> ok, so having read my link, 1) this is indeed due to 'set termguicolors' 2) but at least on my end something else is wrong -- with this change vim starts up as if notermguicolors, then on first keypress (which it swallows) it switches to termguicolors

12:19 <ovf> so it 'feels' as if vim messes up the terminal control sequence state machine and only gets the reply to decide to do termguicolors after a keypress

12:20 <ovf> ultimately i guess more vim problem than foot's

12:28 <dnkl> ovf: I remember seeing several issues related to this

12:29 <dnkl> think it's been resolved in vim already

12:29 <dnkl> but perhaps not in a release yet

12:30 <ovf> i hadn't woken up yet so i resorted to bisecting from vim's git master, this one is still there

12:32 <ovf> but also apparently vim's default gui colorscheme is just ugly, seeing that first thing in the morning was a much harder blow than the state machine bug

12:32 <dnkl> then I think this is somewhat intended; they detect RGB support asynchronously. Though not seeing the response until after a key press sounds not so ideal...

12:33 <ovf> it definitely shouldnt't swallow that keypress

14:25 <dnkl> anarcat: looks like it's been fixed. Not a terminal issue after all ;)

18:56 <Guest69> is yambar has signal? like dwmblocks ?