The cursor colors in gogh weren't imported quite right; this
fixes things up so that we use the background color together
with the cursor color from the scheme.
refs: https://github.com/wez/wezterm/issues/4257
* First step towards implementing #4226.
* Added InputSelector config options.
* Format + fix to prepare for PR to resolve#4226.
* Accept suggestion about pop().
* Fix typo.
* Tried fixing stuff from the feedback.
* Fixed typo.
* Fixed small mistake in docs.
* Small fix for label computation.
* Allow uppercase alphabet + add fuzzy_description.
* Minor cleanup.
* Use more standard alphabet (without j/k).
* Fixed docs after previous commit.
* Added key assignments to docs.
* Apply suggestions from code review (2 remaining)
* Updated arcording to feedback (added tests).
* Update docs (1 thing left to do)
* Added version details to the key table.
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Root cause is that font-config will try to find a single font that
satisfies a query like `fc-list ':charset=2686 3065'`, but if that
is impossible, there are no results.
The resolution is to split the query up and look for each individual
codepoint.
refs: #4310
Previously we'd use the scaled-by-line-height-and-cell-width dimensions
for the text cursor, leading to oddly dimensioned block cursors when
`line_height` or `cell_width` were configured.
This commit captures the native cell dimensions into the RenderMetrics
which makes it feasible for the glyph and sprite rendering logic to
reason about it.
The cursor rendering now renders at the native size and position by
using a transform to scale and translate into the correct spot.
We could potentially use the same technique for eg: braille or
other non-drawing characters
(https://github.com/wez/wezterm/issues/1957) although that is more
complex than just this commit.
refs: https://github.com/wez/wezterm/issues/2882
Previously we'd return the Url string. Now we provide a Url
object that provides access to the various elements of the Url.
This will cause slightly breakage for folks that were treating
it as a string in their status event handlers, for example.
The docs have been updated to show how to run with both this
new Url object and also continue to run on older versions of
wezterm.
They now also show how to manually percent decode the url
for older versions of wezterm.
refs: https://github.com/wez/wezterm/discussions/4157
refs: https://github.com/wez/wezterm/issues/4000
Move the shortcode aliases out from the various emoji category
pages and into a new shortcode page.
Add variations, such as skin tones, to the different emoji
category pages.
* Allow set_environment_variables to set the SHELL.
Previously, we'd always set it to the shell from the password
database. Now we do that by default, but if set_environment_variables
has been used, we'll preserve that value for the environment
of the to-be-spawned process
* Clarify the docs:
* Remove the confusing version dependent sections that started
with old behavior and rewrite in terms of the behavior that
has been true for the past year
* I've heard from a few people that they tried to change COMSPEC
on Windows and pain ensued. Try to nudge them to read the
next paragraph that tells them what they are actually supposed
to change.
refs: https://github.com/wez/wezterm/issues/4098
refs: https://github.com/wez/wezterm/issues/4168
closes: https://github.com/wez/wezterm/issues/3816
refs: https://github.com/wez/wezterm/issues/3317
The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
The approach we were using previously was to ask macOS for the fallback
font list, but it didn't include the correct fonts for certain
codepoints.
Switch to using an alternative API that asks macOS which font to use for
a specific codepoint.
refs: #4099
This is primarily to improve the chances of displaying an arbitrary
image without resorting to additional external tools, that may be
difficult or impossible to install.
refs: #3716
refs: #3264
otherwise, the termwiz line reader can become confused and
fail to recognize key presses like `(` which have SHIFT and LEFT_SHIFT
set.
refs: https://github.com/wez/wezterm/issues/3999
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
Feels safest to do this until we can make a smoother fallback
experience for webgpu.
I will revert this after tagging the release so that nightly
runs webgpu by default.
Relocate the helper function to mux-server-impl and have both the GUI
and the mux server call it at the appropriate times.
Introduce default_mux_server_domain which is used instead of
default_domain in the mux server. This is to avoid recursive
cycles when starting up the mux; we don't want the default
domain to be a unix client that connects to our selves because
we'll try to connect to ourselves, then in act of handling that
spawn in the default domain and try to connect to ourselves and
repeat.
refs: https://github.com/wez/wezterm/issues/3907
* Change aliasing to exact matches of the color data.
* Don't "GC" away schemes that are no longer reachable from aggregators;
just because they are no longer listed elsewhere, doesn't mean that we
should remove the name/scheme from wezterm if it was already made
available in an earlier release.
refs: #3831
This is fixing a regression introduced by the fix for #2845.
The resolution for this is relatively straightforward, but took a bit
of effort to plumb.
Previously:
* CTRL/ALT/SUPER-modified keys with no explicit expansion would end
up just taking the US layout version of the key. That worked well
for the intended problem with non-latin layouts, but for eg: German
layouts it caused expansion to totally the wrong thing
Now:
* CTRL/ALT/SUPER-modified keys which effectively expand to non-ascii
text (eg: cyrillic "Es") now take the equivalent key press from the
US layout (which would be "c" in the "Es" case). For European
layouts this heuristic seems to avoid unexpected effects, but could
do with some validation from native users.
To support this, the xkb code splits the `Keyboard` struct out from
some of the higher level logic and introduces a `KeyboardWithFallback`
struct that is built out of the user-selected keyboard layout, and
the fallback keyboard. Now the fallback keyboard is fed the same
key inputs as the selected keyboard to correctly model the key
combinations.
refs: #3610
refs: #3933
ssh connection or host authentication errors would not be displayed
when the config was in its default exit_behavior=Close state.
This commit introduces some plumbing to allow a pane to override
the effective exit_behavior value, so that ssh sessions can now
rewrite it to CloseOnCleanExit while they are in the process
of connecting.
refs: #3941
Given a sequence like this, where the `ESC [ K` sequence is
emitted at the last column when wrap_next=true:
\u001b[47;30m 17:24:50 \u001b[0m\u001b[K
rather than treating the column as out of bounds, we'd clear the
final cell.
refs: #3548
Avoid a "flash" of a single black but likely overly stretched and
awkwardly interpolated frame while we wait for big/animated/complex
images to load and decode.
For corrupt images, or images with an incorrect or typo'd filename in
the config, this prevents us from punting and just showing a transparent
background instead of something reasonable.
There were a couple of layers of issue here:
* In the ImageDataType::decode method, we didn't detect and do something
reasonable when the decoded image had 0 frames, later leading to
a panic in glyphcache when trying to index frame 0 of an empty vec.
* We shouldn't have been using ImageDataType::decode for window
background images
* Make the fallback/placeholder black rather than fully transparent
in the more modern decoder thread routine that we use for image
decoding at the gui layer.
refs: #3614
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
For eg: RU layout, CTRL-S shouldn't result in ы in the context
of a terminal.
The approach taken here is similar to kitty; when the key combination
doesn't produce a definitive composed output, and when any of
ctrl/alt/super are present, we treat the keypress as though it were
the same as the one from the system default keymap.
The result is that ctrl-c now works like ctrl-c and alt-b and alt-f work
like their latin counterparts.
Hopefully there are no downsides to this!
refs: https://github.com/wez/wezterm/issues/2845
refs: https://github.com/kovidgoyal/kitty/issues/606
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.
This pulls in almost all of the original PR in #2235.
I skipped a dead key case that I recall being tricky:
I didn't want to break the non win32-input mode version
of that.
I'd be happy to have that case re-evaluated in a smaller
PR where we can focus on its details.
Co-authored-by: Dominik Kreutzer <kreudom@gmail.com>
For whatever reason, it appears as though the wayland
frame event stuff is unreliable when used with webgpu,
so we simply avoid using it.
refs: https://github.com/wez/wezterm/issues/3126
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.
Previously, we'd record the focused pane only in the per-client
view.
That status didn't propagate through the model fully, leading to
inconsistencies when using activate-pane-direction.
This commit does the full model update to force that through.
I may regret this later: the focus state was intended to be
a per-client attribute and this effectively prevents that
from ever being useful.
Maybe the per-client state should just be removed?
Will ponder that later.
refs: https://github.com/wez/wezterm/issues/3448
refs: https://github.com/wez/wezterm/issues/3387
Also sneaking in here is not updating the last input time
for a client unless the input was taken by a user.
This had a referencing issue, similar to the more recent GLOBALS
issue.
The resolution in this case is a lot simpler: we can just return
a regular lua table and use all the same underlying semantics,
but stick a metatable over the top to handle assignment and
provide the strict mode method.
If the target domain_id doesn't match the source pane.domain_id(),
then we consider the filesystem namespace to be incompatible and
won't try to use it.
refs: https://github.com/wez/wezterm/issues/3442
The server-side ownership of the palette is a stumbling block for
many users, so let's fix it.
This commit allows the client to pass its configured palette to
the server when it connects, and when the config is changed.
That palette takes precedence over the palette from the server config.
However, if the remote application uses any escape sequences that
redefine the color palette, the color palette that was active at
that point in time is forked and use as the basis, and will remain
the active palette until the palette is reset via escape sequences.
refs: https://github.com/wez/wezterm/issues/2686
refs: https://github.com/wez/wezterm/issues/3397
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.
This got broken around the time we started to re-exec the mux
server. Since the fd was CLOEXEC we'd essentially unlock and
ignore the lock at the point we'd re-exec.
This commit allows the fd to remain open and locked across
the exec, and causes the exec'd process to set CLOEXEC by
explicitly telling it about the log fd, so that shells and
things spawned by the mux don't hold the lock.
Work harder to notice and handle the PaneRemoved notification
more centrally, which allows removing some earlier workarounds.
Now when we receive PaneRemoved, we take the opportunity to handle
missing mapping or stale mapping between local and remote ids and
perform a resync before continuing to handle the PaneRemoved message.
Doing it this way means that we don't need to second guess the timing
of notification or the resync, so we end up with the correct sequence
of notifications, and the result is the correct size of the splits
because the local and remote aren't independently managing the
the pane removal with conflicting ideas of the new size.
refs: https://github.com/wez/wezterm/issues/3386
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
