10:00 <w0rm> so at some point in the past I was mentioning that I had foot server randomly quit in some situations. Well - I have a reproducer now but haven't tracked down the culprit...

10:01 <w0rm> When I run "pkill kanshi && kanshi &" things work as normal. Except I forgot to do '&!' in zsh so kanshi is not detached from the shell

10:02 <w0rm> when I try to quit the terminal/shell where I ran this command zsh warns that I have unfihished jobs. When I actually ignore the warning and quit - foot server teminates

10:03 <w0rm> I wonder if anyone could try the above if they have kanshi/zsh - might help narrow down my search

10:05 <w0rm> notably - I can't trigger this with anything else other than kanshi

10:05 <w0rm> obviously I have a solution - do a proper job detach when running kanshi so it's not a big deal

10:56 <dnkl> w0rm: can't you compile a debug version of foot and get a backtrace?

10:57 <dnkl> or maybe you already have it; if you have a core dump, and your distro provides debug packages

10:57 <dnkl> s/packages/symbols

11:42 <w0rm> I can do that but the thing is foot doesn't actually crash

11:43 <w0rm> it looks like it cleanly exits - there's logs about broken wayland connection but I think that might be from kanshi itself. I'll play around a bit with logging to narrow it down

11:58 <w0rm> so this is what happens just before the exit: https://dpaste.com/4LTKU5V4E

11:58 <w0rm> and the output is not from kanshi (I redirected that output)

12:57 <dnkl> w0rm: that means the compositor closed the connection to foot.

12:57 <dnkl> could be an issue with the compositor

12:58 <dnkl> or that there's a flood of events not being handled quickly enough

12:59 <dnkl> try running the foot server with WAYLAND_DEBUG=1, and redirect the output to a file

13:00 <dnkl> hmm, that looks like a bug in Sway, that should be fixed in latest master

13:02 <dnkl> or maybe wlroots. Can't remember

13:03 <dnkl> https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3487

13:30 <w0rm> that looks like a good match

13:37 <w0rm> I'll see if I can get a backport of that patch or update to master/RC and see if I can still reproduce

14:29 <dnkl> w0rm: if it still reproduces, try to get the WAYLAND_DEBUG=1 output. It's likely a race in the compositor/wlroots, similar but not identical to the wlroots issue mentioned above

18:21 <hardcoresushi> Hi, I'm using aerc mail client with foot. I uses its embedded terminal running neovim to compose mails. However, colors are incorrect when enabling 'termguicolor' (for example cyan foreground when using gruvbox theme).

18:21 <hardcoresushi> I can reproduce this with default config for aerc, foot and neovim.

18:22 <hardcoresushi> It works fine when changing the TERM environment variable or when disabling 'termguicolor'.

18:22 <hardcoresushi> I'm asking help here but I'm not sure whether it's a problem with foot or aerc.

18:44 <dnkl> hardcoresushi: have you tested aerc+neovim in other terminal emulators?

18:45 <dnkl> if that works, either aerc or neovim is most likely during comparing TERM, instead of looking at the actual terminfo. i.e it's very unlikely a bug in foot

18:56 <hardcoresushi> dnkl: Yes it works fine in kitty

18:58 <hardcoresushi> Thanks for the explanation, I will report this on the #aerc channel

18:59 <hardcoresushi> (I think it's more likely to come from aerc than from neovim)

19:05 <dnkl> fwiw: s/during/string

19:16 <dnkl> hardcoresushi: are you using latest aerc (0.13)?

19:17 <dnkl> the changelog says the terminal backend in aerc was changed in the last release

19:17 <dnkl> aerc+neovim seems to work for me (with aerc 0.13)

19:20 <hardcoresushi> Yes, aerc 0.13.0-1 from debian:sid

19:52 <w0rm> dnkl: FYI I tested on sway 1.8 rc2 and it's not happening anymore

19:56 <dnkl> w0rm: good to hear, thanks!

21:37 <hardcoresushi> Is there a way to dynamically change the background alpha value of foot ?

21:38 <dnkl> hardcoresushi: you can use an OSC-11 escape sequence: https://codeberg.org/dnkl/foot/src/branch/master/doc/foot-ctlseqs.7.scd#L628-L633

22:04 <hardcoresushi> dnkl: Awesome! Thank you very much

22:05 <hardcoresushi> Btw, I was wondering if it's possible to pipe the scrollback in a program executed in the current terminal, and not as a background process