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:

image

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:

https://github.com/jwilm/alacritty/blob/44037fa42aa80002ce54f0a8e4a6203e3e12aaf5/alacritty/src/main.rs#L75-L81

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)

Most upvoted comments

I’m slightly confused by this line of discussion. My suggestion of spawning windows was as an alternative: we could spawn a new conhost window, 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.

Yeah, I’m saying that I agree.

Is there an issue in WSL that causes linking with #![windows_subsystem = “windows”] to make it so we can’t block until the program exits?

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.

At least that’s the two options I understood based on @davidhewitt’s input and based on these, I definitely think that our alacritty -v & option is far better.

I’m slightly confused by this line of discussion. My suggestion of spawning windows was as an alternative: we could spawn a new conhost window, 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.

Ideally running alacritty … from within any console should always open a new window.

Do you mean it should always open a new Window, meaning Alacritty, or do you mean that running alacritty in powershell.exe should always open another powershell.exe window?

👍 let’s go with that