Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
fixes:
* beginning the selection with the top right or bottom left corner
* beginning the selection with the bottom right corner and only select a single line
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 commit re-arranges the code so that an overlay can have a local
stack of key table activations; this allows copy_mode and search_mode
key tables to layer on top of the user's window level key tables.
Previously, we'd just stick the search_mode entry on top of the global
state, which worked, but had the undesirable side effect of hijacking
the Enter key when switching to another tab in the window.
refs: https://github.com/wez/wezterm/issues/993
The copy overlay now has a notion of running in search mode vs. copy
mode; it can be launched in either mode.
Search mode has a separate key table called `search_mode`.
Activating copy mode while search mode is active will now update
the mode of the existing overlay, rather than cancelling and creating
a new instance, and vice versa.
Activating copy mode while search mode is active will replace the
current key table activation (which is assumed to be `copy_mode`)
with `search_mode`, and vice versa.
The viewport is no longer scrolled to the bottom when activating search
mode.
refs: https://github.com/wez/wezterm/issues/993
refs: https://github.com/wez/wezterm/issues/1592
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
Moves the key handling in the copy overlay to be driven entirely
by configurable key assignments.
Note: copy mode wants you to use the `Copy` assignment to actually
do the copy, but this implementation hides the normal key assignments
by activating the copy mode key table. This will be addressed
in the following commit.
refs: https://github.com/wez/wezterm/issues/993
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
If we had previously killed all the panes in a remote mux,
and then reconnected to it using the launcher menu attach option,
we could end up in a confusing state where we connect but don't
show anything for the remote; it looks like nothing happened
even though it is legitimately showing the empty remote mux.
This commit checks for that case and spawns the default program
in the remote if there are no panes.
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
When the screen is cleared/reset, the physical top is not reset with it,
instead the scrollback_top variable gets set with the point at which the
screen was reset / you are allowed to scroll back to. The scroll bar
code wasn't aware of that.
refs: https://github.com/wez/wezterm/issues/1866
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.
Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
This is definitely in the band-aid category, but two issues have
mentioned the AA in custom block glyphs recently.
This commit adds an `anti_alias_custom_block_glyphs` option that can be
set to false to prevent the custom block glyphs from enabling AA.
I think a better long term fix would be some kind of hinting to avoid
the degenerate AA case, but when I made an enquiry about this class of
issue in tiny skia in the past, the author didn't want to diverge from
skia-compatible behavior, so I think we'd need to find (or build!) an
alternative rasterizer for these path instructions.
refs: https://github.com/wez/wezterm/issues/1753
refs: #1817
To fix this correctly, the mux protocol would need to have some
special cases for talk to a gui server implementation, and we don't
have those today.
refs: #1794
The glium IncompatibleOpenGl Display doesn't include any of the
useful context to explain what the issue was, so this commit
renders the error both in human friendly and Debug form to
see if we can understand more about what is happening.
refs: https://github.com/wez/wezterm/issues/1813
* gui: improve mouse text selection
* implement mouse press capture between the terminal and UI, so when you
start selecting text from the terminal the tabs won't activate and
vice-versa
* selecting from the top and bottom lines won't scroll the viewport
anymore, it will only scroll if the mouse is moved out of line bounds
* change cell selection so that it behaves like text selection usually
does in other popular software
refs: https://github.com/wez/wezterm/issues/1199
refs: https://github.com/wez/wezterm/issues/1386
refs: https://github.com/wez/wezterm/issues/354
`ActivateKeyTable` pushes a new named key table entry onto the stack.
It has some parameters:
* name - required; the name of a entry in `key_tables` that should be
activated.
* timeout_milliseconds - how long the entry should remain active.
When this duration elapses, the entry will pop itself from the
stack. If omitted, the entry will not pop itself due to time.
* one_shot - if true (or omitted; true is default), the entry will pop
itself after one use. If false the entry will not pop itself after use.
But note that if timeout_milliseconds is set then it may pop itself
due to time.
* replace_current - if true, will pop the current stack entry before
activating the current entry. Most useful when combined with some
other one_shot=false activation.
`PopKeyTable` explicitly pops the top of the key table stack.
Most useful with `one_shot=false` activations.
`ClearKeyTableStack` clears the key table stack. Most useful with
`one_shot=false` activations.
```
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
local name = window:active_key_table()
if name then
name = "TABLE: " .. name
end
window:set_right_status(name or "")
end);
return {
debug_key_events = true,
keys = {
-- Activate the "woot" table as a one-shot with
-- a 2 second timeout, after which it will restore
-- the default table.
{
key="a", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
timeout_milliseconds=2000,
}
}
},
-- Activate the "woot" table.
-- The table will remain active until explicitly popped
-- by the `PopKeyTable` action. See the Escape binding below!
{
key="b", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
one_shot = false,
}
}
},
-- Activate the "woot" table as a one-shot with
-- no timeout. It will remain active until a key is pressed,
-- after which is will restore the default table.
{
key="c", mods="CTRL",
action=wezterm.action{
ActivateKeyTable={
name="woot",
}
}
},
},
key_tables = {
woot = {
{key="a", action=wezterm.action{SendString="woot"}},
{key="Escape", action="PopKeyTable"},
},
},
}
```
This commit introduces a new `key_tables` config option that allows
defining named groups of key assignments, but that have no effect yet.
To support this change, the InputMap type has been adjusted to allow
for the idea that multiple tables can exist.
refs: https://github.com/wez/wezterm/discussions/1812
The gist of the issue is that when setting eg: scale=1.2 to draw
a larger CJK glyph, it is drawn at the same descender level, which
makes it more likely to leave the top of the cell.
This commit adjusts the y position by the difference between the
original and the scaled descender so that is less likely to cause
problems.
refs: https://github.com/wez/wezterm/issues/1803
This is mostly a refactoring: pulling out the discrete width/height from
the `new_window` method and preparing to pass down x/y coords as well.
The types are expressed as Dimension so that screen relative sizes could
be expressed in the future... once we know how to obtain that
information on each platform.
refs: https://github.com/wez/wezterm/issues/1794
The tab bar height could vary by a couple of pixels depending on the
text shown inside it, which results in visual jitter as the title bar
changes.
Avoid that: always return our constant reserved amount of space for the
tab bar, even if it means that there are a couple of pixels "wasted".
cc: @davidrios
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
In https://github.com/wez/wezterm/pull/1779#issuecomment-1082058134 we
discuss a weird case where the tab bar height is computed as 0 and then
gets stuck at 0.
What's happening is that the initial `TabBarState::default()` value has
no items yet, and `build_fancy_tab` generates an area that occupies 0
pixels. This computed element is cached, and then the height from that
is cached.
When `invalidate_fancy_tab` is called, it didn't invalidate the cached
height and the resultant metrics were wonky.
One possible fix for this was to also invalidate the cached height,
but since that height is already stored in the built fancy tab,
we can remove that derived-cached value in favor of just passing
down the value.
refs: https://github.com/wez/wezterm/pull/1779
- Simplify scroll thumb calculations
- Correct thumb position when dragging with mouse
- Support border OS parameters
- Use usize for OS borders, to explicitly only accept positive integers
- Get correct tab height when using fancy tab bar
- Correctly draw depending on tab bar position
- Adjust minimum thumb size to be 1/2 of a cell height, so it has consistent size across platforms and screen densities
Fixes#1525
The condition should be: dpi-changed && (close-enough-stuff)
but was (dpi-changed && (some-close-enough-stuff)) ||
(other-close-enough-stuff).
The net result was toggling non-native full screen on macos could
falsely try to do scale change handling even though the dpi was
unchanged, because the window resized by only a couple of pixels.
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
Separates out window vs pane click-to-focus behavior more distinctly,
and fixes up the behavior when
swallow_mouse_click_on_window_focus=false.
refs: #1540
wezterm cli spawn, and wezterm cli split-pane can use this information
to pick a default for the pane id when invoked from outside of wezterm.
refs: https://github.com/wez/wezterm/issues/1531
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
* Detect mouse leaving the window
* Implement leave
* Use new API
* Fix mouse leave
* Fix mouse leave on Wayland
* Mouse leave on X11
* Detect mouse leaving window on macOS
* Fix example
refs: #1434
This change also allows removing the dep on the palette crate,
which I found to be difficult to use (API changed often, and relied
on a lot of `.into` that was hard to follow and reconcile across
upgrades). We already pulled in the csscolorparse crate as an indirect
dep of colorgrad, so we can replace the color conversion we need for
sixel with that crate while we're in here.
refs: #1615
This is using the existing attributes on the lines and rendering
the lines with doubled dimensions.
Selection on double width lines is a bit wonky because we don't
know how to translate the column position correctly.
This commit allows the following configuration:
```
wezterm -n --config 'colors = { selection_fg = "clear", selection_bg = "rgba:50% 50% 50% 50%" }'
```
which sets the selection_bg to fully transparent, and selection_bg to
50% transparent gray.
When selection_fg is fully transparent we'll use the normal fg color.
When selection_bg is partially (or fully!) transparent, it will be
alpha blended over the current cell background color.
To support this, the config file will now accept rgba colors specified
as 4 whitespace delimited numeric values. If a value ends with `%` it
is interpreted as a number in the range 0-100. Otherwise, it is
interpreted as a number in the range 0-255. The 4 values are
red, green, blue, alpha.
At this time, only the selection_fg and selection_bg settings accept
alpha values.
refs: #1615
Resolves a little bit of the awkward duplication of color types
between some of the crates by factoring them a little bit better.
This is prep for allowing specifying alpha for some colors
in the config.
This puts to final rest #478, wherein ligatured glyphs that span
cells would render portions of the glyph with the wrong fg color,
where wrong was usually the bg color and cause the glyph to turn
invisible when cursoring through the ligature.
The approach used here is to divide the glyph into 7 discrete strips
where each strip either intersects with the cursor, the selection, or
neither. That allows us to render each strip with the appropriate
foreground color.
This change simplifies some of the logic and allows some other code
to be removed, so that feels good!
As is tradition with these renderer changes, there's a good chance that
I overlooked something in testing and that the metrics or alignment
might be slightly off for some font/text combo. Let's see how this
goes!
refs: #784
refs: #478
refs: #1617
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
This is a more robust approach; we make a separate pass to figure
out information about the (harfbuzz) cluster for a sequence of glyphs,
and then map that sequence back to the original cell sequence, and
from there compute the total cell width for the run, then distribute
the glyphs across the run.
This should yield more sane results for bidi.
Fixup the x-position math; it was still wonky despite the
efforts in 5f2c905db8 and
af92265ffb
refs: #1570
refs: #1607
refs: #1563
This allows unicode_version to be respected again when rendering.
The updated emoji-presentation.sh script now highlights this slightly
better by putting `.` characters after the emoji; unicode version 14
emoji presentation will show the `.` in the 3rd column, while earlier
versions will show it in the 2nd column for glyphs that are sensitive
to the version.
refs: #1607
refs: #1563
This commit does two related things, from opposite ends of the spectrum:
* Sets the sticky bit on pid files and unix sockets to avoid tmpwatch
deleting them in cleanup scenarios
* Falls back to looking at the changed time if the filesystem doesn't
support reporting creation time when wezterm does its own liveness
and cleanup checks for unix domain sockets in the runtime dir
* Allow any wezterm instance to perform that cleanup
refs: #1601
with:
```
bidi_enabled = false,
bidi_direction = "RightToLeft",
```
lines are now rendered right-justified in the terminal.
I think there's still work to do on this, because the cluster
order seems weird to me, but it's hard for me to intuit how
this should really look.
refs: #784
This commit refines bidi property handling:
* experimental_bidi has been split into two new configuration settings;
`bidi_enabled` (which controls whether the terminal performs implicit
bidi processing) and `bidi_direction` which specifies the base
direction and whether auto detection is enabled.
* The `Line` type can now store those bidi properties (they are actually
split across 3 bits representing enabled, auto-detection and
direction)
* The terminal now has a concept of active bidi properties and default
bidi properties
* The default properties are pulled from the wezterm configuration
* active bidi properties are potentially set via escape sequences,
BDSM (which sets bidi_enabled) and SCP (which sets bidi_direction).
We don't support the 2501 temporary dec private mode suggested by
the BIDI recommendation doc at this time.
* When creating new `Line`'s or clearing from the start of a `Line`, the
effective bidi properties are computed (from the active props,
falling back to default propr) and applied to the `Line`.
* When rendering the line, we now look at its bidi properties instead
of just the global config.
The default bidi properties are `bidi_enabled: false` and
`bidi_direction: LeftToRight` which corresponds to the typical
bidi-unaware mode of most terminals.
It is possible to live reload the config to change the effective
defaults, but note that they apply, by design, to new lines being
processed through the terminal. That means existing output is
left unaffected by a config reload, but subsequently printed lines
will respect it. Pressing CTRL-L or otherwise contriving to have
the running application refresh its display should cause the
refreshed display to update and apply the new bidi mode.
refs: #784
This commit is larger than it appears to due fanout from threading
through bidi parameters. The main changes are:
* When clustering cells, add an additional phase to resolve embedding
levels and further sub-divide a cluster based on the resolved bidi
runs; this is where we get the direction for a run and this needs
to be passed through to the shaper.
* When doing bidi, the forced cluster boundary hack that we use to
de-ligature when cursoring through text needs to be disabled,
otherwise the cursor appears to push/rotate the text in that
cluster when moving through it! We'll need to find a different
way to handle shading the cursor that eliminates the original
cursor/ligature/black issue.
* In the shaper, the logic for coalescing unresolved runs for font
fallback assumed LTR and needed to be adjusted to cluster RTL.
That meant also computing a little index of codepoint lengths.
* Added `experimental_bidi` boolean option that defaults to false.
When enabled, it activates the bidi processing phase in clustering
with a strong hint that the paragraph is LTR.
This implementation is incomplete and/or wrong for a number of cases:
* The config option should probably allow specifying the paragraph
direction hint to use by default.
* https://terminal-wg.pages.freedesktop.org/bidi/recommendation/paragraphs.html
recommends that bidi be applied to logical lines, not physical
lines (or really: ranges within physical lines) that we're doing
at the moment
* The paragraph direction hint should be overridden by cell attributes
and other escapes; see 85a6b178cf
and probably others.
However, as of this commit, if you `experimental_bidi=true` then
```
echo This is RTL -> عربي فارسی bidi
```
(that text was sourced from:
https://github.com/microsoft/terminal/issues/538#issuecomment-677017322)
then wezterm will display the text in the same order as the text
renders in Chrome for that github comment.
```
; ./target/debug/wezterm --config experimental_bidi=false ls-fonts --text "عربي فارسی ->"
LeftToRight
0 ع \u{639} x_adv=8 glyph=300 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
2 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
4 ب \u{628} x_adv=4 glyph=244 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
6 ي \u{64a} x_adv=4 glyph=363 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
9 ف \u{641} x_adv=11 glyph=328 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
11 ا \u{627} x_adv=4 glyph=240 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
13 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
15 س \u{633} x_adv=10 glyph=278 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
17 ی \u{6cc} x_adv=4 glyph=664 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
19 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
20 - \u{2d} x_adv=8 glyph=276 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
21 > \u{3e} x_adv=8 glyph=338 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
```
```
; ./target/debug/wezterm --config experimental_bidi=true ls-fonts --text "عربي فارسی ->"
RightToLeft
17 ی \u{6cc} x_adv=9 glyph=906 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
15 س \u{633} x_adv=10 glyph=277 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
13 ر \u{631} x_adv=4.78125 glyph=272 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
11 ا \u{627} x_adv=4 glyph=241 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
9 ف \u{641} x_adv=5 glyph=329 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
6 ي \u{64a} x_adv=9 glyph=904 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
4 ب \u{628} x_adv=4 glyph=243 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
2 ر \u{631} x_adv=5 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
0 ع \u{639} x_adv=6 glyph=301 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false})
/System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText
LeftToRight
0 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
1 - \u{2d} x_adv=8 glyph=480 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
2 > \u{3e} x_adv=8 glyph=470 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false})
/Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
;
```
refs: https://github.com/wez/wezterm/issues/784
This commit centralizes the focus-loss logic to the Window so
that activating a new tab will deactivate the pane in the current
window.
Note that this cannot see overlays in the gui, but overlays shouldn't
care about focus, so it should be ok.
refs: https://github.com/wez/wezterm/discussions/796
This commit enables the following config to work for local (not mux yet!)
panes:
```lua
local wezterm = require 'wezterm'
wezterm.on("format-tab-title", function(tab, tabs, panes, config, hover, max_width)
if tab.is_active then
return {
{Background={Color="blue"}},
{Text=" " .. tab.active_pane.title .. " "},
}
end
local has_unseen_output = false
for _, pane in ipairs(tab.panes) do
if pane.has_unseen_output then
has_unseen_output = true
break;
end
end
if has_unseen_output then
return {
{Background={Color="Orange"}},
{Text=" " .. tab.active_pane.title .. " "},
}
end
return tab.active_pane.title
end)
return {
}
```
refs: https://github.com/wez/wezterm/discussions/796
We budget size based on the x_advance, which can be 1 pixel less
than the width of the glyph texture, so we could often end up
omitting the last character in "Launcher" or "default" in the
tab title or right status area.
This commit uses x_advance in both places.
Make the scrolling mostly independent of the active row; adjust
the top row when hitting the top/bottom edges of the display.
Mouse movement no longer changes the scroll position. Instead,
the wheel is used to scroll the list.
refs: https://github.com/wez/wezterm/issues/1485
This isn't ideal, but it is better than previously: we would
close the window and before the Drop impl had updated the
list of known windows, we'd try to re-assign that window
to another mux window in a different workspace, but it would
never appear because the window was closed.
refs: https://github.com/wez/wezterm/issues/1531
Originally I had this the other way around but it was problematic
when considering things like maximized, font scaling and full screen
states.
refs: https://github.com/wez/wezterm/issues/1531
Rather than just quitting the app and potentially silently killing off
a number of panes that might be running in other workspaces, we now
will pick one of those workspaces and activate it.
refs: #1531
This action causes the active workspace for the gui to change.
If the name is omitted a random name will be generated.
If the workspace doesn't exist, it will be be created.
The optional spawn parameter can be used to launch a specific
program into the new workspace; if omitted, the default prog
will be used.
The gui only supports a single active workspace. Switching workspaces
will repurpose existing gui windows and re-assign them to windows
in the new workspace, adjusting their size to fit those windows,
spawning new windows or closing unused windows as required.
The gui now exits when there are no panes in the active workspace,
rather than no panes at all.
refs: #1531
The mux now has a notion of which client is actively doing things.
This allows, for example, newly spawned windows to take on the
active workspace for a given client.
The gui now assigns a client id on startup, and sets the active
workspace to `default`.
The mux server temporarily overrides the active id to that of
the currently dispatching client when processing PDUs.
refs: https://github.com/wez/wezterm/issues/1531
Tidies up some code duplication within the mux protocol handler.
Move some of the logic into Mux, remove legacy Spawn Pdu to reduce
more duplication.
I want to dedup some of the similar logic that exists in the gui
spawn implementation as well in a follow up.
`ScrollByPage` can accept non-integer values in the configuration.
This allows fractional page scrolling, such as by half a page.
The default remains the same, at 1 page.
This is not exposed through any UX; the mux api allows setting
the workspace and propagating information about windows whose
workspace has changed.
Windows start with a blank workspace name.
This is just plumbing; nothing uses it yet.
refs: #1531
This is a similar race condition to one we had before with the
multiplexer, where the connection UI made us think that we didn't
need to start a new process.
Additionally, the attach method would unconditionally create a
new client without checking whether we already had one.
In the case that the published symlink is stale, our default
client connection logic was to retry connecting with backoff
to give a newly spawned server a chance to startup.
In the context of a newly launched gui process checking to see
if an existing gui process can serve the same request, we don't
need to give it any grace: it will either answer immediately
or be deemed not useful.
This commit limits us to a single connection attempt in the case
where we're not automatically starting the server, which in turn
constrains the overhead to something in the order of microseconds
rather than nearly 0.5 seconds.
While we're in here, I noticed that if we thought we had a socket
to try and that failed, we'd always try to publish a new symlink.
However, if we failed due to mismatched version info, we shouldn't
publish over the top of the already running instance.
refs: #1529
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
This puts us in a better position for the future to be able
to configure whether we use wezterm, tmux or no multiplexing.
Today we allow wezterm or no multiplexing.
Add docs on this new setting.
refs: https://github.com/wez/wezterm/issues/1456
If an ssh domain is set to use_multiplexer=false, it is now
possible to `wezterm connect` to it.
Previously, it was only possible to connect to domains that
used the mux client.
refs: https://github.com/wez/wezterm/issues/1456
If we decide we want re-use and existing gui due to config differences
we shouldn't then publish the new, differently configured, gui as
the canonical path for that display/class.
Clarify the message that we print when re-using an existing gui
in case someone doesn't want that behavior.
When set, changes the default domain to the domain with the specified
name, which potentially affects the default program.
eg: default_domain = "WSL:Ubuntu-18.04" will cause the initial tab
to be spawned via WSL.
The idea is that we want to be able to spawn into wsl with the
convenience of a local domain, but without the awkwardness of
it having a different filesystem namespace.
It would also be great to be able to spawn a new tab or pane
in the same domain and pick up the cwd of the existing one.
The WslDomain allows the user to explicitly list WslDomains
and control eg: default shell, username and so on, but wezterm
will pre-fill a default list of domains based on the `wsl -l`
output that we were already using in the launcher menu.
The existing LocalDomain has been augmented to understand that
it may need to fixup a command invocation and that gives it
the opportunity to rewrite the command so that we can launch
it via `wsl.exe` and pass down the cwd and so on.
This same technique might be extensible to eg: docker instances
in the future.
This commit:
* Introduces `wsl_domains` config and its default list of wsl
distributions
* Creates LocalDomain instances from that list
* The launcher menu allows spawning a new tab via one of those domains
The client machinery would try to spawn an async attempt at
detaching the unixdomain from the mux on shutdown, but since
we're in the middle of tearing down the scoped executor,
we could sometimes panic.
The client we have in this situation isn't actually associated
with a domain, so we don't need to detach in that situation.
Formalize that by making it an Option, and address the
fanout.
Using the new publish/discovery stuff from the past couple of commits,
if we can find a matching socket path for a running gui, and the
configuration is likely a match, then use the mux protocol to talk
to the already running gui and ask it to spawn the equivalent program
into the same process.
refs: https://github.com/wez/wezterm/discussions/1486
We need 100% of the info for it to work correctly, so this commit:
* Exposes the keyboard encoding mode via the Pane trait
* Adds the scan code to the RawKeyEvent
* Has the GUI perform the encoding if the keyboard is set that way
* Removes the basic encoder from termwiz in favor of the gui level one
The net result is that we bypass the Pane::key_up/Pane::key_down methods
in almost all cases when the encoding mode is set to win32-input-mode.
There is now a config option: allow_win32_input_mode that can be
used to prevent using this mode.
refs: #1509
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.
Nothing generates them right now, and the mux client has no
way to represent them on the wire.
I'm considering constraining them to just win32 for now.
refs: https://github.com/wez/wezterm/issues/1509
It was showing the whole text for the cluster for each shaped
glyph.
Fix it up to map back to the corresponding cell range and
extract the text from the line.
Include the x_advance metric in the output while we're in
there.
refs: https://github.com/wez/wezterm/issues/1333
When rendering the IME composing text, I noticed that for the Korean
input sequence: shift+'ㅅ' followed by 'ㅏ' we'd render the 'ㅆ' (the
shifted first character) in black and the composing 'ㅏ' in white
against the cursor color, and that was very difficult to read,
especially at the default font size.
To resolve this, this commit:
* Forces clustering to break around the cursor boundary, so that
we treat the cursor position as its own separately styled cluster
* Adjusts cursor/bg rendering so that we always consider the start of
the cluster for the colors of that run. We are guaranteed that a
ligatured sequence will fit in the background area anyway.
This has the effect of "breaking" programming ligatures such as '->'
when cursoring through them, and decomposing them into their individual
'-' and '>' glyphs, which is a reasonable price to pay for being able
to see things better on screen.
refs: https://github.com/wez/wezterm/issues/1504
refs: https://github.com/wez/wezterm/issues/478
When we translate a dead key, send the composed event immediately
and don't try to route the current key press via the IME.
Improve rendering when in the composing state: overlay the composing
text at the cursor position to show what the composing text would
look like, even though it hasn't been committed to the input stream
yet.
refs: https://github.com/wez/wezterm/issues/1504
For Korean text input, pressing SHIFT and then typing in certain
keys begins a composition sequence. Our logic for when to route
via the IME got so distracted by ALT that it didn't consider SHIFT
and didn't send this sequence to the IME, so we'd fail to compose
those sequences.
While poking at this, I realized that we should treat this composition
similarly to dead keys, in that we can signal the term window to
highlight the cursor color and report that status.
There's some further work to do: the composing text should be rendered
by us. So far our IME integration assumes that the IME itself will
render over the top of our window, but for this particular input
it doesn't do that.
refs: https://github.com/wez/wezterm/issues/1504
The same core code is used to render both the tab navigator
and the launcher. The context is specified using some flags
so that you don't get an unholy mess in both places.
The net result of this is that the tab navigator now supports
fuzzy matching.
refs: #664
refs: 1485
* Allow selecting the first few rows by number
* Allow scrolling through long lists of items
* Add actions from key assignments to list
refs: #1485
refs: #1413
Since we now have RawKeyEvent and a sane way to indicate handling,
we don't need these any more, and it simplifies key dispatch to
remove them.
refs: #1483
Pass down whether we are in a live resize to the gui layer, so that
we don't incorrectly assume that the scale has changed, and fight
with the window manager.
Built this on my mac: will need to fixup for windows and linux.
refs: https://github.com/wez/wezterm/issues/1491
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",
},
}
```
When set, the cursor will change to this color during dead key
or leader key processing.
```lua
return {
colors = {
dead_key_cursor = "orange",
},
}
```
refs: #686
refs: #688
on macos only (for now), we generate a RawKeyEvent prior to
dead key or IME composition and route it to the window to give it
a chance to handle the event.
RawKeyEvent handling is scoped only to key assignments, not generating
input for the terminal.
A raw key event can be marked as handled to prevent moving on to
performing composition and generating cooked key input.
refs: https://github.com/wez/wezterm/issues/877
```lua
local wezterm = require 'wezterm'
return {
debug_key_events = true,
keys = {
{key="phys:Q", action=wezterm.action{SendString="woot"}},
},
}
```
The above will send "woot" to the pane whenever the key in same
physical position as Q on an ANSI standard US keyboard is pressed.
refs: https://github.com/wez/wezterm/issues/1483
This comes from a time where our quads were always locked to grid
positions. We don't need it any more: we can simply add the adjustments
to the quad positions that we set.
Removing it makes the vertex a bit smaller and reduces the amount
of GPU accessible memory we need to use.
I'm running down a weird thing where the main font renders weirdly
when the title font is 12 pt vs the main font 10 pt.
I thought there might have been a cache invalidation issue and
realized that we could have an A-B-A style issue with the font_ptr
stuff, so I replaced it with an incrementing id.
That didn't fix the thing I was looking at, but does feel a bit
nicer overall.
The default we use on macOS looks decent. Roboto is a similar
looking font that we can use for the other platforms.
I may make it the same on all three once I've had a chance
to compare it on a mac.
Previously, we would implicitly set it to the special SEQ_ZERO
value, but since that value always flags the row as changed,
it causes some over-invalidation issues downstream in wezterm.
This commit makes that parameter required, so that the code that
is creating a new Line always passes down the seqno from that event.
refs: #1472
We only need to recompute when the tab content changes, or when
the window is resized, plus invalidations of the shape cache
of texture atlas filling up.
Hover events don't need to re-shape.
We can now also place the tab bar at the bottom of the screen again.
The main tab area now takes the background color from the first
cell in a formatted tab bar item as the full background color
for the whole tab area, which looks a lot nicer than just the
using that color for the minimal bounding box of the tab text.
