alacritty: Windows: `-v` does not hold terminal foreground
A downside of linking with #![windows_subsystem = "windows"] is that alacritty.exe will return immediately when launched from a command line.
This means that alacritty -v can potentially write output to the terminal while the user is attempting to do other interactions, like so:
It seems there’s not much that can be done about this. It’s a bit of a sad state about how Windows works. We definitely want to link with #![windows_subsystem = "windows"] because otherwise starting alacritty from the desktop will spawn a console window too (yuck!).
I suggest we keep things as-is but I add a note to the following comment explaining that AttachConsole will cause output to overlap:
Alternatively we could change it so we only write log output to files on Windows. But I’m not a fan of that, as the terminal logging is very helpful for development & debugging.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (15 by maintainers)
Yeah, I’m saying that I agree.
It’s not a WSL thing, it’s a Windows OS thing. Because we link with
#![windows_subsystem = "windows"], no matter how we launch Alacritty, it will never block the shell it was launched from.I’m slightly confused by this line of discussion. My suggestion of spawning windows was as an alternative: we could spawn a new
conhostwindow, and send the logs to that window, rather than our current solution of sending logs to the parent shell Alacritty was launched from. But I’d personally rather send logs to the parent shell, even if we can’t block it.Do you mean it should always open a new Window, meaning Alacritty, or do you mean that running
alacrittyinpowershell.exeshould always open anotherpowershell.exewindow?👍 let’s go with that