Open jefferai opened 2 years ago
Hey @jefferai, long time no see!
termenv is querying the terminal for its current settings via control sequences on stdout, and the terminal is expected to respond by printing to stdout, which termenv reads from. There's a timeout of 5 seconds defined, after which the read
should be aborted: https://github.com/muesli/termenv/blob/master/termenv_unix.go#L112
It looks like waitForData
is reporting data to be available, but then the read
call blocks waiting for a single byte. I haven't seen that on any of my (test-) systems so far.
Could you verify whether bytes are actually slowly trickling in or if it's stuck there waiting for a response that'll never arrive?
Hi @muesli π
It's definitely not 5 seconds. Sometimes it's 2 or 3; often it's 10 or so; sometimes (very rarely) it's 30 or more. I don't think I've seen it completely freeze forever.
How would you want me to verify that bytes are trickling in? Just fork the lib and print debug out?
I can also see if it happens in other envs. I'm running on arm64 M1 on Monterey 12.2.1 in iTerm using zsh. I did try with bash without any difference. Stock terminal makes no difference.
After more investigating, the real cause for me was from lipgloss.AdaptiveColor
which call termenv.HasDarkBackground()
to determine the background color as @jefferai stated, replacing the adaptive color with normal color solved the issue.
@r4ndomx That observation is correct, yeah. I think I finally figured out under which circumstances this is happening: if the first background detection happens only after bubbletea has taken over control of stdin/out, the communication channel between terminal and termenv is essentially broken. You could work around this issue by manually calling lipgloss.SetHasDarkBackground(termenv.HasDarkBackground())
once before initializing your bubbletea app.
We'll clean this up and may have to refactor the API a bit here. See upcoming work in next
branch.
Is there any update on having this issue fixed within lipgloss
itself?
My understanding is that the issue arises because Bubbletea
holds a lock on the os.Stdout
file descriptor, which prevents lipgloss
from performing terminal background color checks required for adaptive colors.
Calling lipgloss.SetHasDarkBackground(termenv.HasDarkBackground())
does indeed fix the issue. A potential alternative solution might involve using a shared mutex to synchronize access to the file descriptor, but this would only be needed if the background color was changing (though I'm sure there's also some caching involved that would need to be updated too).
In the meantime, I think it would be helpful to update the README to mention this issue under the Adaptive Colors
section. This would save other developers a lot of time in figuring out the problem.
Thank you!
@mikecbone Noted! For what it's worth we have some upcoming features that both run background color detection in a non-blocking way and let you opt out of it entirely.
I am still having this issue as of version v0.12.1
when using list.New on fedora 41.
@ElectricPulse How about with v1.0.0
?
If you're still having that issue as of that version, can you post some source code we can use to reproduce the issue?
Sometimes when running my program (very similar to the fancy list demo and using the same lipgloss variables), when my list is created, I see a very long pause. It doesn't happen all the time -- over half the time, but not every time -- but that pause can take anywhere from a few seconds to 30 seconds or more. I got a
SIGQUIT
stack trace -- it's down intermenv
so let me know if you'd rather I post there than here, but since my entrypoint there islipgloss
I figured I'd start here.Let me know what other info I can provide. Thanks!