The issue here was that we'd try to match this:
```
key_event RawKeyEvent { key: Char('t'), modifiers: ALT | LEFT_ALT, phys_code: Some(T), raw_code: 17, repeat_count: 1, key_is_down: true, handled: Handled(false) }
```
which has mods=`ALT|LEFT_ALT` against `ALT` and would fail.
We need to strip out the positional ALTs from the modifiers
in order to successfully match.
refs: https://github.com/wez/wezterm/issues/1958
This change causes key table activations to effectively layer
over prior key table activations.
This is necessary for the copy mode key assignment changes to
work.
refs: https://github.com/wez/wezterm/issues/993
I've bundled this into termwiz's UnicodeVersion type as that is
a similar concept that is already routed through to the appropriate
function.
refs: https://github.com/wez/wezterm/issues/1888
The launcher menu code to perform attaching has been generalized
into a key assignment action and reimplemented in terms of that
action.
A detach action has been added to disconnect and detach.
refs: https://github.com/wez/wezterm/issues/1874
This commit allows the currently active window to:
* Spawn a new tab in the active window (rather than spawning
a new window) to host the connection status
* Auto-close that connection UI tab (rather than the whole window)
when the window is no longer needed
* Pass the current window through to use as the primary window when
assigning remote window/tabs.
The net effect of this is that there are fewer transient windows,
and that it is easier to connect a set of domains to the active
workspace.
refs: https://github.com/wez/wezterm/issues/1874
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
This persuades vim to set ttymouse=sgr by default.
We're carefully sitting below 279 which triggers
some queries for things that we don't respond to yet.
refs: https://github.com/wez/wezterm/issues/1825
Some versions of fontconfig classify some fonts as having charcell
spacing. We need to consider those as monospace as well.
refs: https://github.com/wez/wezterm/issues/1820
The keys section was way too big; this splits it up into more
manageable pieces, adds a nice flow chart to show how key events
are processed and adds an example of using the new key tables feature.
A bit of a PITA, this commit:
* Introduces a DeferredKeyCode type that defers resolving a concrete
keycode
* Adds key_map_preference config which can be Mapped or Physical
* Key map building resolves the keycode using key_map_preference
* Default key assignments have been re-phrased in order to produce
DeferredKeyCodes
* User-specified keys without `mapped:` or `phys:` prefixes will
resolve according to key_map_preference
refs: https://github.com/wez/wezterm/issues/1788
refs: https://github.com/wez/wezterm/issues/1784
Previously, we'd create a clipboard handler associated with a GUI window
and take care to pass that down to the underlying Pane whenever we
spawned a new pane.
For the mux server, instead of being associated with a GUI window, the
clipboard was a special RemoteClipboard that would send a PDU through
to the client that spawned the window.
The bug here was that when that client went away, the clipboard for
that window was broken.
If the mux server was the built-in mux in a gui process this could
leave a tab without working OSC 52 clipboard support.
This commit restructures things so that the Mux is responsible for
assigning a clipboard handler that rephrases the clipboard event
as a MuxNotification.
Both the GUI frontend and the mux server dispatcher already listen
for mux notifications and translate those events into appropriate
operations on the system clipboard or Pdus to send to the client(s).
refs: #1790
After killing the remote pane, we no longer trigger the renderable
poll stuff that would detect that the pane was dead.
Let's speculatively set it to dead so that we don't get stuck with
stray tabs/panes.
https://github.com/wez/wezterm/issues/1752
There were a a couple of issues:
* `ImageData::hash` would re-hash the image on every call, and this was
called for every cell that comprised an image on the mux server side
* `SerializedLine` needed to understand how to remove the `Arc<ImageData>`
image attachments so that we didn't serialize a complete copy of the
image per cell that comprised the image.
A new RPC was introduced to attempt to fetch `ImageData` given its
content hash and pane, row and cell index as a hint to locate it.
A client side LRU of content hash to `ImageData` is used to avoid
issuing repeat calls to that new RPC.
refs: #1237
Flesh out the get_os_parameters impl for macOS. When running on a
system that provides `NSScreen::safeAreaInsets`, use that to determine
the border required to avoid the "notch" on certain models of mac.
In the GUI layer: when the os parameters include a border, adjust
the render position to account for it.
This is a bit of a speculative change, as I don't have a mac with
a notch.
refs: https://github.com/wez/wezterm/issues/1737
This helper extracts the concrete set of hosts and their configurations
from the ssh config, and arranges to reload the wezterm config if they
are changed.
This is useful when constructing ssh domain configs.
refs: https://github.com/wez/wezterm/discussions/1731
The `open` crate blocks forever when spawning the browser via xdg-open,
which feels kinda "wrong" to me, but does offer a method that can stick
that in a background thread, so that's what we do here.
refs: #1721
For a sequence like `e U+20d7` the intent is to render the `e` with
a vector arrow over the top.
This is typically implemented by fonts as an `e` followed by the
vector glyph (or vice versa), where either one of those may have
a zero advance so that the two elements are combined.
There were two problems here:
* During shaping we'd see the zero advance and assume that the entry
was useless and skip it
* During rendering, if we didn't think it had any cell width, we'd
not render it
Cursoring through that particular sequence can hide the vector
mark if the cursor is set to the default block cursor due to annoyances
in how the block cursor is rendered (it changes the fg color to match
the bg, but for elements outside where we think the cursor is, this
makes those elements invisible).
refs: https://github.com/wez/wezterm/issues/1617
Built using:
```
./FontForge-2020-11-07-21ad4a1-x86_64.AppImage --script $PWD/font-patcher "$PWD/src/unpatched-fonts/NerdFontsSymbolsOnly/NerdFontsSymbolsOnly Template 1000 em.ttf" --powerline --use-single-width-glyphs -out /tmp/nerd-fonts-out --fontawesome --fontawesomeextension --fontlinux --octicons --codicons --powersymbols --powerline --powerlineextra --mdi --weathericons
```
which is everything *except* Pomicons at the time of writing, pending
clarifications of its distribution license
(https://github.com/ryanoasis/nerd-fonts/issues/266)
refs: https://github.com/wez/wezterm/issues/1521
The issue is that we work hard to match the keys pre-composition,
but for French and Norwegian layouts ALT-number are valid,
useful punctuation keys. It's awkward to make exceptions for
ALT keys when matching assignments, especially on macOS, and
the simplest thing to do is simply to remove the assignments
and leave it to our users to add their own if they want them.
The ctrl-shift and cmd based assignments are generally much
easier to keep, because those key combinations are not widely
used default mappings on any keyboard layout.
refs: #1543
refs: #1542
refs: https://github.com/wez/wezterm/pull/1132
user vars were stubbed out. This commit adds storage for them
in the mux client and adds a new notification that publishes each
var as it is changed. That differential stream is applied to the
storage in the mux client when it is received.
```lua
local wezterm = require 'wezterm'
wezterm.on("update-right-status", function(window, pane)
local woot = pane:get_user_vars().woot
window:set_right_status(tostring(woot))
end);
return {
unix_domains = {
{name="unix"},
},
}
```
then running:
* `wezterm connect unix`
* in that session: `printf "\033]1337;SetUserVar=%s=%s\007" woot `echo -n nice | base64``
causes `nice` to show in the status area.
refs: #1528
When spawned with no WEZTERM_UNIX_SOCKET environment set,
we now prefer to resolve the gui instance, falling back to
the mux if it doesn't look like the gui is running.
`wezterm cli --prefer-mux` will use the original behavior of
trying to resolve the path from the unix domain in the config.
This commit adds a couple of helper methods that provide insight into
the state of the keyboard layer.
The intent is for users to add status information about the keyboard
state.
This commit also ensures that we schedule an update when the leader
key duration expires, and ensures that we close out the leader state
for an invalid key press.
refs: #686closes: #688
```lua
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
local leader = ""
if window:leader_is_active() then
leader = "LEADER"
end
local dead = ""
if window:dead_key_active() then
dead = "DEAD"
end
window:set_right_status(leader .. " " .. dead)
end);
return {
leader = { key="a", mods="CTRL" },
colors = {
dead_key_cursor = "orange",
},
}
```
Previously, we'd take a couple of guesses at how to map the key
to a utf8 value, but! the keyboard state has a method that can tell
us what to use.
This is important in non-latin keymaps where, for example, the `c`
key generates cyrillic small letter es and we'd end up sending
CTRL + that through to the terminal when CTRL is held down.
If we get the utf8 string from the keyboard layer then we get
CTRL+c instead, and that is what we want.
refs: https://github.com/wez/wezterm/issues/678
