Open goerz opened 1 month ago
There does seem to be a possible workaround, which I tried on a lark:
open -n -W -a $HOME/Downloads/WezTerm-macos-20240922-151228-2b76c63b/WezTerm.app --args --config-file $HOME/.config/wezterm/neovim.lua start --always-new-process -- /opt/homebrew/bin/nvim
The workaround does indeed work, see the neovim
wrapper in my configuration. So this doesn't seem like a high-priority issue, but still buggy behavior.
What Operating System(s) are you seeing this problem on?
macOS
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
20240922-151228-2b76c63b
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When starting
WezTerm
by issuing the command(or even just
wezterm start
, and also if usingwezterm-gui
), the window that opens is in the background:https://github.com/user-attachments/assets/cbc49829-6bb2-498b-b670-3d766862996c
This happens whether issuing
wezterm start
from another terminal, or via any other way of running a command (a shell script inside a Keyboard Maestro macro, in my case). The only way to start WezTerm in the foreground is to open theWezTerm.app
.To Reproduce
Open the macOS built-in
Terminal
app.Run
Configuration
no config
Expected Behavior
A new
WezTerm
GUI app instance should appear, active and in front of my existing windows (as if I had launched theWezTerm.app
in the GUI)Logs
Anything else?
I came across something similar recently in https://github.com/neovide/neovide/issues/2330, and the resolution there – using the deprecated
-[NSApplication activateIgnoringOtherApps:]
API – might be applicable here as well.In fact, this issue with WezTerm came up while trying to set it up as a wrapper for
neovim
. I'd be interested in any workarounds for a background shell script running something likeand having that WezTerm window appear in the foreground.