Further constrain the hiding logic for key-down events, so that
we are less likely to hide for things ctrl-shift-c when the user
is mousing around and copy/pasting.
Also, consider CapsLock to be a modifier for this and other
similar purposes.
refs: #3570
refs: #3306
The main part of the problem is that NSWindow::isZoomed lies to us
sometimes.
This is a relatively gross workaround.
Add missing invalidation after setting the content size; that prevents
janky when dragging the window between monitors.
Removed some redundant Dimensions computation from that method; nothing
ever read it.
refs: https://github.com/wez/wezterm/issues/3503
It's a little limited in the scope of its detection: we have a built-in
list of tiling WM environments and if the current one is on the list
then we set an appropriate value for this option.
The list currently has just a single entry.
We need access to the underlying raw/physical key in order
to correctly encode in some modes, so we need the full KeyEvent
struct for that.
Move the encoder up so it sits alongside the win32 input mode
encoder.
This should give us better results for both shifted/unshifted
and the "base layout" (US english) representations of a number
of keys.
Note that this is still not 100% technically correct: the unshifted
keys require knowledge of the keyboard layout that we don't have
at this OS-independent layer.
Right now we're assuming a US layout to unshift punctuation, which
is not right if you're not using that layout. To resolve that,
more work is needed on each OS to be able to extract that information
and then to store it in the KeyEvent.
refs: https://github.com/wez/wezterm/issues/3479
refs: https://github.com/wez/wezterm/issues/2546
We were missing encoding of these for the base xterm encoding
(I haven't daily driven a keyboard with a numpad in over 10 years!).
Improve mapping for the kitty protocol.
refs: https://github.com/wez/wezterm/issues/3478
This commit teaches the termwiz layer about positional modifiers,
and expands our modifier concept to also pass through led states
such as caps lock and num lock.
Those aren't actually keyboard modifiers, but the state is useful
to recognize.
Adjust the shift key normalization so that we don't uppercase
alpha characters when both SHIFT and CAPS_LOCK are held.
This processing will remove both SHIFT and CAPS_LOCK in that
situation.
Add a method to KeyEvent that will undo the OS keyboard layer
normalization of positional to generic modifier key presses.
eg: the OS may map LeftControl -> Control, but we actually
prefer to have LeftControl so if we can unambiguously reverse
that mapping, we do so.
refs: #3476
refs: #3475
The stack trace in https://github.com/wez/wezterm/issues/3425
shows a recursive borrow triggered indirectly by spawning
a subprocess and having that trigger the wndproc.
This commit doesn't really fix the recursive problem, but may
sidestep it, and it's probably best to avoid always running
the `wsl` command to get this list anyway, similar to the
change in 25255d90d6
refs: https://github.com/wez/wezterm/issues/3425
These conditions were from the earliest days of panes and aren't
needed any more, especially because they make it hard to have
consistent behavior!
refs: https://github.com/wez/wezterm/issues/3450
I think the future for this is to extend the Pattern type to accept
a list of regexes and use a RegexSet to unambiguously handle multiple
patterns with captures.
That might help a little with https://github.com/wez/wezterm/issues/3247
but the stated use in that issue may not even work with the rust
regex crate.
For now we do the simple thing and match the user's patterns
first.
refs: https://github.com/wez/wezterm/issues/3456
Allows prompting the user to select from a list and then
triggering some action on the selected item.
This is the guts of the launcher menu hooked up to user-supplied
arbitrary entries.
I dug out my pixelbook which has intel graphics and runs linux
to try to make sense of this issue, but I'm baffled.
It doesn't appear to NaN going in, but we end up with something
weird happening if we don't fixup the alpha.
Relevant entry to the discussion/background on this is:
https://github.com/wez/wezterm/issues/1180#issuecomment-1496102764
I don't think it's worth sweating over this, so let's just suck it
up.
refs: https://github.com/wez/wezterm/issues/1180
* character select pgup/down support for bigger jumps
* fix jerky selected_row clamping, keeps selected center offset
* die dead code
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
* thx silly rustisms
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
* charselect movements now spcified by amount, or 0 which does full pgsz
* rustfmt
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
In the spawn initial mux case, we didn't verify that the mux
had no windows with the requested workspace, so we'd start up
with just the default session spawned by the mux when it starts
up.
This commit tries a bit harder to confirm that there is matching
domain/workspace combo before deciding that it is sufficient.
refs: #2734
I noticed that in debug builds, `wezterm set-working-directory` had
high/variable latency, and I traced part of it to the ssh config parsing
logic.
Make that lazily evaluate the ssh config.
refs: #3402
Finally getting around to wrapping this up; previously you had
to define your own format-tab-title event handler if you wanted
to show the title that you had set via `tab:set_title`.
Now, if that string is not empty, it will be used instead of
the title string from the active pane.
refs: #1598
The pixel sizes are too tiny on my retina mac display, so I wanted
to make them larger. I noticed that the background color was transparent
which resulted in the appearance of a cross behind the button; that's
due to the way that the rounded corners are applied, so we need to
explicitly fill the background with the same color.
Refactor to make changing the size in the future a DRY operation,
but I left the size as-is because it needs more finesse and
I want to come back to that tomorrow.
Remove an unsafe global variable and replace with a member variable
that works similarly to the drag tracking.
Doing this from a mac... may not compile on a windows box!
Broken config could cause the gui to exit before it would normally
print the config warnings and errors, making it harder to understand
what is going on.
This commit bundles the config error text together with whatever
caused it to error out in the fatal error case.
Now that we have a more regular domain-shaped serial thingy,
refactor the `wezterm serial` command to re-use the common
gui setup and running logic. This removes some FIXMEs from
around the wonky setup of the domain, which is nice.
This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
It's a tremendous PITA for the user to do this at the system level on a
mac, where it is sorely needed. This commit allows raising to a desired
minimum level, but won't decrease from an already larger soft limit.
refs: https://github.com/wez/wezterm/discussions/3353
Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This fixes a surprising interaction between copy mode and the
command palette, but is also the root cause of another issue
with CharSelect mode.
refs: https://github.com/wez/wezterm/issues/2947
On macOS prefer CMD, but on other platform prioritize shortcuts
that don't use CMD, as those tend to reserve the CMD based shortcuts
for the system.
Allow specifying how many shortcuts to show if an action has
multiple assignments. The default is 1.
refs: https://github.com/wez/wezterm/issues/3335
added a new `ui_key_cap_rendering` option that accepts the following
values:
```lua
-- Super, Meta, Ctrl, Shift
config.ui_key_cap_rendering = 'UnixLong'
-- Super, M, C, S
config.ui_key_cap_rendering = 'Emacs'
-- Apple macOS style symbols
config.ui_key_cap_rendering = 'AppleSymbols'
-- Win, Alt, Ctrl, Shift
config.ui_key_cap_rendering = 'WindowsLong'
-- Like WindowsLong, but using a logo for the Win key
config.ui_key_cap_rendering = 'WindowsSymbols'
```
refs: https://github.com/wez/wezterm/issues/3335
For items in the main set of key assignments, show the keyboard
shortcut to the right.
Some items have multiple key assignments; we show only the first
one. We'll probably want to be a bit smarter. For instance,
both linux and windows tend to occupy the Windows/Super key
assignments, so we should probably prioritize showing the Ctrl+Shift
variants on those platforms.
refs: https://github.com/wez/wezterm/issues/3335
Given an assignment like this:
```
{
key = "b",
mods = "ALT",
action = wezterm.action.SplitPane {
direction = 'Right',
command = {
label = 'Bash Right',
args = {'/usr/bin/bash' }
}
}
}
```
we should show the label from the command in the palette.
That's what this commit enables.
If there is no label, but the arguments are set, then the
arguments will be shown instead.
refs: #3252
