* Taught wezterm-mux-server how to `--daemonize` on windows
* Removed pty based command spawn used to spawn unix domain servers.
This was present because it was the only way to successfully spawn
wsl in the past. What I'm finding today is that it doesn't work
at all for me, generating an `0xc0000142` Application failed to
initialize error. A plain command builder spawn seems to work,
so that's what we're going with.
* Ensure that we put `.exe` on executable name on windows, otherwise
the spawn may fail.
* `Path::exists()` always returns false for unix domain sockets on
Windows, so unconditionally try to remove the socket before binding,
otherwise the bind will falsely fail, claiming that another process
is already bound.
The docs for mux will need to be updated to show how to revise them
for the new mux server invocation:
```lua
unix_domains = {
{
name = "wsl",
serve_command = {"wsl", "wezterm-mux-server", "--daemonize"}
},
}
```
This version no longer generates invalid CA certificates and
allows TLS connections using the internal PKI to advance
further. Still need to debug an early disconnect.
kindof a lot going on in this commit, unintentionally:
* Need the lua context set to be moved into the config crate
otherwise configs cannot be parsed by the server and we end
up with the default configs
* Make the server use smol for async io
* Drop the use of the daemonize crate, which I had forked anyway.
Just inline our own tighter daemonize module
* Improve daemon spawning synchronization, however, it still needs
work for windows to avoid blocking forever where we don't do
daemonizing.
Rather than having each call site add a window to the mux and then
call the front end to spawn a window, make the mux emit a signal
advising of a window spawn, and have the front end subscribe to
that signal.
There was a flaw in processing the built-ins; because we searched
the built-ins as part of the font dir step we'd satisfy matching
the default fallback from the in-memory fonts and it would accidentally
take precedence over the fonts provided by the system font locator.
This commit makes an explicit additional (final) step to search
the built in fonts.
refs: #263
When confirmation is enabled, a really basic overlay is
rendered over the top of the tab to request confirmation.
The default key assignment for CloseCurrentTab now
has confirmation enabled.
```lua
action=wezterm.action{CloseCurrentTab={confirm=true}}
action=wezterm.action{CloseCurrentTab={confirm=false}}
```
refs: https://github.com/wez/wezterm/issues/157
refs: https://github.com/wez/wezterm/issues/280
When confirmation is enabled, a really basic overlay is
rendered over the top of the pane to request confirmation.
```lua
action=wezterm.action{CloseCurrentPane={confirm=true}}
action=wezterm.action{CloseCurrentPane={confirm=false}}
```
refs: https://github.com/wez/wezterm/issues/157
refs: https://github.com/wez/wezterm/issues/280
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
If we've failed to initialize EGL, try setting `LIBGL_ALWAYS_SOFTWARE=true`
in the environment and make another pass at initialization in the hope
that it brings up something usable.
This commit only impacts linux systems at the time of writing.
I've made the line that logs the GL implementation information
have `error` level again, because it is more convenient for me
even if it isn't technically an error.
refs: https://github.com/wez/wezterm/issues/272
(but isn't the true fix; this is just trying to make the consequences
of that problem less. I would like to get that fixed correctly)
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
(which discusses what I think the end state should be)
