We want to avoid normalizing control key presses; there were
two places where it was happening; one in our own code and
the other was in the xkeyboard mapping stuff itself.
refs: https://github.com/wez/wezterm/issues/1851
checkout seems to be failing for ubuntu 20 recently:
```
Deleting the contents of '/__w/wezterm/wezterm'
Initializing the repository
/usr/bin/git init /__w/wezterm/wezterm
Initialized empty Git repository in /__w/wezterm/wezterm/.git/
/usr/bin/git remote add origin https://github.com/wez/wezterm
Error: fatal: unsafe repository ('/__w/wezterm/wezterm' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /__w/wezterm/wezterm
Error: The process '/usr/bin/git' failed with exit code 128
```
Try reverting this as a workaround.
There are certain key combinations that macOS prefers to handle
without giving the application much opportunity to process them.
CTRL-ESC and CMD-. both cause doCommandBySelector(cancel:) to be
called. The former we had already special cased but since we
can't disambiguate the two things, we need a better way.
performKeyEquivalent: is a method we can implement to have an
opportunity to "do something" and prevent the default macOS behavior.
So we implement that. What's interesting is that saying that we handled
CMD-. results in no further processing at all by macOS, whereas saying
that we handled CTRL-ESC results in macOS doing the normal key event
dispatch. So we need to route that event for ourselves in that one
case.
Doesn't feel great!
refs: https://github.com/wez/wezterm/issues/1867
Use some heuristics to verify the data that is about to be parsed;
this can help to detect eg: data being output to stdout prior
to us sending any encoded data to the remote mux.
In addition, add a timeout to help avoid waiting forever in
the case that we didn't detect a problem.
refs: https://github.com/wez/wezterm/issues/1860
I'm not totally sure this is all there is to it, but in #1850
the response is showing up after vim was exited, so it seems like
it didn't fully receive these responses.
refs: #1850
Create a list of command definitions to hold the default key
assignments.
That list has more metadata, such as a brief and longer human
readable description of the purpose, and allows for (in the
future) reasoning about the context where the command is valid,
as well as providing more information when rendering in the
launcher menu.
refs: https://github.com/wez/wezterm/issues/1485
The heart of the issue here was due to the window-reuse logic that
tries to reuse a GUI window that is no longer associated with a mux
window.
Each GUI window subscribes to the mux for mux events, but it filters
according to is understanding of the mux_window_id that it is associated
with.
The GUI frontend maintains an mapping of GUI and mux window so that it
knows when to reuse a GUI window and when to close it.
When connecting to a remote mux, wezterm spawns a temporary connection
progress window. Once connected, workspace reconiliation is triggered
and decides that this window can be used for something else.
As part of workspace reconciliation, this mapping can be adjusted and
the frontend will notify a GUI window that its mux window has changed.
However, that updated mux window was not visible to the mux notification
subscription so the effect was that a variety of notifications were
effectively ignored, including updates from a remote mux when the output
was changed.
To make matters worse, the workspace reconciliation could "double-tap"
window creation and create excess windows only to later realize they
weren't needed and close them out again.
This commit addresses both of these concerns.
refs: #1841
refs: #1814
We're now capable of remembering an alpha value for everything
in the palette and the main window theme, but not the tab bar theme.
Whether the alpha is correctly respected at render time is a different
story!
refs: #1835
The bug here was that each paint call in a window would update
the focus state of its panes to reflect the one that had focus.
However, it didn't account for the actual window focus; it would
just assume that it was focused.
The result was that the perceived focus would alternate between each of
the windows in the wezterm process, and if you were running an
application that had enabled focus tracking, those events could cause a
repaint and drive up the CPU utilization.
This commit addresses that by gating the focus update to only occur
when we have the focus, and for extra safety, avoid generating focus
events at the terminal layer if the new state matches the current state.
refs: https://github.com/wez/wezterm/issues/1838
I wanted to use the Target::Pipe feature of env_logger so that we could
log to a log file as well as stderr, but it just doesn't work
(https://github.com/env-logger-rs/env_logger/issues/208).
Since we were already composing over the top of the logger in order
to capture data for our ringlog, this commit embraces that and makes
our logger responsible for both stderr and log file printing.
Thankfully, we can use the filter parsing code from env_logger to
avoid having to get too crazy with this.
Logs are stored in the runtime directory and look something like:
/run/user/1000/wezterm/wezterm-gui-log-596324.txt
Logs are collected on all platforms.
There isn't currently a thing to clean up logs.
