When running the GUI, we generate a unix domain socket path for
the current process and start up a mux server for that path.
This allows `wezterm cli list` and `wezterm cli split-pane` to
work implicitly inside the GUI session.
When started in this way, the mux server is not persistent;
when the GUI process is terminated, all of its windows, tabs
and panes are terminated.
refs: https://github.com/wez/wezterm/issues/230
Revise logging so that we use info level for things that we want
to always log, and adjust the logger config to always log info
level messages.
That means shifting some warning level logs down lower to debug level so
that they aren't noisy.
closes: https://github.com/wez/wezterm/issues/388
This helps keep the config object a bit smaller and the trace logging
output less verbose.
We now memoize the effective palette in the config, which should shave
off a little bit of time in the renderer.
This commit moves a bunch of stuff around such that `wezterm` is now a
lighter-weight executable that knows how to spawn the gui, talk to
the mux or emit some escape sequences for imgcat.
The gui portion has been moved into `wezterm-gui`, a separate executable
that doesn't know about the CLI or imgcat functionality.
Importantly, `wezterm.exe` is no longer a window subsystem executable
on windows, which makes interactions such as `wezterm -h` feel more
natural when spawned from `cmd`, and should allow
`type foo.png | wezterm imgcat` to work as expected.
That said, I've only tested this on linux so far, and there's a good
chance that something mac or windows specific is broken by this
change and will need fixing up.
refs: #301
