joncrangle
commented
2 months ago I found that using the title before domain worked better. For sshmux domains, Wezterm is able to guess the foreground process and set the title to that process, so it made sense to check that before checking the domain. This works well on Mac and Linux.
Wezterm sometimes fails to correctly guess the foreground process on Windows, and will show the running shell process (pwsh.exe in my case) rather than its child process. This is a Windows issue, and to get around it the user would need to alias commands using env vars (see discussion in https://github.com/wez/wezterm/issues/3597). I can't think of a way to get around this within the plugin, but it isn't breaking since this component will still always return a value, with 'wezterm' being the fallback default.
The PR updates the match statement so that it covers Windows directories (backslash for dirs) as well as unix-based systems (forward slash).
I created this as a draft because I'd like to test it some more on various platforms with different processes running and also to get some feedback.
If a foreground process isn't found (which is expected behaviour for most non-local domains), the idea is to then check the domain name. If it isn't a local domain, we would then use the domain name for the process name, because resolving the foreground process won't be possible.
If we're dealing with a local domain and couldn't resolve a foreground process name, the idea is to use the tab title as the process name. Wezterm will attempt to resolve the OSC 1/2 sequences to fill in a title name (see get_title in Wezterm docs), and the title will default to "Wezterm" otherwise.
I know Windows has some odd behaviour with OSC 2 sequences that I'd like to test further as well to see what the tab title gets set to, and whether we would need to do some matching for Windows PCs.