`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
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
This commit allows specifying a scaling factor as part of the font
attribute definition. This scaling factor is fed through to the
rasterizer and the shaper to adjust the actual font size that is
loaded.
The intent is to provide manual control for situations where the
fallback font has a different scale to the primary font and renders
either too small or too large.
The concrete example is
https://github.com/wez/wezterm/issues/1761#issuecomment-1079708207 where
the CJK fallback looks too small.
The scaling factor doesn't influence font metrics so it may also be
desirable to configure line height.
```lua
local wezterm = require 'wezterm'
return {
line_height = 1.2,
font = wezterm.font_with_fallback({
"JetBrains Mono",
{family="Microsoft YaHei", scale=1.5},
}),
}
```
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
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
after reading around italic vs. oblique, I think "slant" is a misleading
way to categorize this, as slant implies something about the angle of
the font but really the difference between italic and oblique is purely
stylistic and without a suggested angle.
style more closely matches the CSS name which is well understood by
many, so we go for that.
refs: #1646
There are three slants that are broadly recognized; normal, italic and
oblique. Prior to this commit, we only considered normal or italic.
This is mostly a mechanical change to replace the boolean with the enum,
and rename the field from `italic` to `slant`.
For the sake of backwards compatibility with existing configs, the lua
helpers for working with fonts continue to accept boolean italic values
and rewrite them to the equivalent slant value.
refs: #1646
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
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
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
Introduce a new config knob called 'local_echo_threshold_ms' to let
users configure when the local echo prediction should kick in. The
default value is 100ms to retain the current behavior.
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 setting now allows specifying what the canonical format is;
previously it was a boolean that meant "don't change anything"
if false, and rewrite to CRLF if true.
It's now an enum with None, CR, LF, and CRLF variants that express
more control.
The config accepts true (maps to CRLF) and false (maps to None)
for backwards compatibility.
The default behavior is unchanged by this commit, however, I did
uncover a bug in the canonicalizer for inputs like `\r\r\n`.
refs: #1575
I generated nerdfonts_data.rs with this shell script; it uses `i_all.sh`
from the nerdfonts repo to get the base mapping:
```
source ./lib/i_all.sh
echo "//! Data mapping nerd font symbol names to their char codepoints"
echo "pub const NERD_FONT_GLYPHS: &[(&str, char)] = &["
for var in "${!i@}"; do
# trim 'i_' prefix
glyph_name=${var#*_}
glyph_char=${!var}
glyph_code=$(printf "%x" "'$glyph_char'")
echo "(\"$glyph_name\", '\u{$glyph_code}'), // $glyph_char"
done
echo "];"
```
Then intent is to use it in wezterm:
```
local wezterm = require 'wezterm'
wezterm.log_info(wezterm.nerdfonts.dev_mozilla)
```
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
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
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.
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
This resolves some issues with non-US layouts (French, Norweigan)
where ALT-number are important and useful punctuation that we were
otherwise blocking.
This new behavior seems consistent with eg: vte terminals on linux
when switching to a French layout.
refs: #1543
refs: #1542
`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.
If we know that the remote host is a unix system, and that it uses some
version of the posix shell, then we can adjust our command line to cd to
the requested directory (as set by OSC 7) and then exec the requested
command.
That's what SshDomain::assume_unix indicates and what this commit does.
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
That top level config/src/lib.rs has been too big for too long.
Break it up a little.
(I recommend running `cargo clean` if you're updating across
this change to avoid a rust ICE with it cached on-disk state)
Previously, it would skip loading the initial config and allow
loading it later by using the reload hotkey. That reload behavior
was an accident!
Another problem with the old approach is that everything else was
set up as if the config had been loaded, which is now causing
confusion for code that wants to decide whether we are using
that configuration or not.
This commit formalizes the skip by remembering that state globally.
This change helps to simplify some special cases around command
line overrides as well, as well as allows cli overrides to take
effect when the user doesn't have a config file.
They have their own versions of these options, and logically it doesn't
make sense to use the default_prog from the `local` domain with a wsl
domain.
refs: #1242
This returns the default set of domains that would be populated
in the wsl_domains config. This is useful if you want to override
eg: the default_prog for specific domain(s), or want to otherwise
add additional variations on the default list.
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
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
* 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
This commit adjusts the config parsing layer so that:
```
return {
keys = {
{key="a", ...}
}
}
```
is now treated as being implicitly the same as `key="phys:A"`.
You can explicitly use `key="mapped:a"` to use the post-keyboard-map
processed value of a key to trigger an assignment, rather than
the physical key location.
refs: #1483
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
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.
This commit adds a CSS box model inspired element / layout
facility, and replaces the hand implemented fancy tab bar
element render.
This makes the code for fancy tab bar much easier to read
and update.
The right status area now expands to the full height of the
tab bar area, and uses a line height of 2.0, which makes
it line up nicely in the tab bar.
This adds string serialization for the keycode and modifiers as
used in the config.
We can't simply tell the base types to serialize in this form because
we may serialize and pass those via the mux protocol and the default
derived serializers are more efficient for that purpose.
This allows:
```lua
local wezterm = require 'wezterm'
return {
keys = {
{key="a", mods="ALT", action=wezterm.action{SendKey={key="b"}}}
},
}
```
to parse: previously, wrapping `SendKey` in `wezterm.action` would fail
to round-trip the the `SendKey` and lead to an error loading the
config.
Rather than hardcode a fixed default value in the config crate, define
the default as optional and leave it to the font crate to compute
the value.
This is a step towards allow introducing system dependent GUI related
code to resolve/understand the title font: we can't put that directly
in the config crate.
There was a discrepancy between leaving it out of the config
and having it partially initialized; fix that up.
Make the default title font size larger on !Windows, as it
looks a bit better.
We might need to make this larger size mac specific.
refs: #1180
Add `get_foreground_process_name` to both Pane and the lua wrapper.
Add `foreground_process_name` and `current_working_dir` fields to
`PaneInformation`. In order for those to be dynamically fetched,
switch the lua conversion for `PaneInformation` to be a UserData
with field access methods. It's a little more verbose but allows
us to lazily compute these two new fields.
refs: https://github.com/wez/wezterm/discussions/1421
refs: https://github.com/wez/wezterm/issues/915
refs: https://github.com/wez/wezterm/issues/876
This is really a timing issue: if shift-click extension of the mouse
selection is used, the user may release the mouse button slightly
after the SHIFT key (which is fine) or vice versa (which was not
previously matched)
refs: #1204
This commit expands quick select mode so that you can trigger it
with distinct sets of patterns (eg: urls on one key assignment,
hashes on a different key assignment), different alphabets,
and lastly, the option to perform a different action from
the default copy action.
You can pair this with `action_callback` to run lua code to
do something with the selected text.
This commit also adds `wezterm.open_with`, a helper function
for opening documents/URLs.
refs: #846
refs: #1362
Adds some plumbing to allow the GUI to implement a download handler
and connect that up for iterm2 image/file transfers that have their
inline property set to false.
Previously we'd just log an error.
Now we will by default download the file to the user's download
directory.
This behavior can be turned off via the new `allow_download_protocols`
configuration setting.
File transfers can be initiated on a remote host via the
https://iterm2.com/utilities/it2dl script.
When the download completes, a toast notification is shown that will
open the file when clicked.
refs: https://github.com/wez/wezterm/discussions/1450
`wezterm.font` and `wezterm.font_with_fallback` can now specify
harfbuzz_features and freetype load/render target and flags as
options on a per-font basis.
This allows you to do things such as adjust shaping (eg: ligatures) or
rendering (eg: disable bitmaps, or adjust hinting) for a single font in
a fallback rather than globally for all fonts.
This got lost somewhere along the way.
Importantly, we need to explicitly set the pty to use invalid stdio
handles for the spawned child in order to avoid a weird situation
where eg: cmd or powershell would end up writing to the log file
despite it being spawned into its own PTY.
refs: #1358
This is a fairly far-reaching commit. The idea is:
* Introduce a unicode_version config that specifies the default level
of unicode conformance for each newly created Terminal (each Pane)
* The unicode_version is passed down to the `grapheme_column_width`
function which interprets the width based on the version
* `Cell` records the width so that later calculations don't need to
know the unicode version
In a subsequent diff, I will introduce an escape sequence that allows
setting/pushing/popping the unicode version so that it can be overridden
via eg: a shell alias prior to launching an application that uses a
different version of unicode from the default.
This approach allows output from multiple applications with differing
understanding of unicode to coexist on the same screen a little more
sanely.
Note that the default `unicode_version` is set to 9, which means that
emoji presentation selectors are now by-default ignored. This was
selected to better match the level of support in widely deployed
applications.
I expect to raise that default version in the future.
Also worth noting: there are a number of callers of
`unicode_column_width` in things like overlays and lua helper functions
that pass `None` for the unicode version: these will assume the latest
known-to-wezterm/termwiz version of unicode to be desired. If those
overlays do things with emoji presentation selectors, then there may be
some alignment artifacts. That can be tackled in a follow up commit.
refs: #1231
refs: #997
* mux: unzoom when switching panes
Add `unzoom_on_switch_pane` config option:
When switching to another pane with ActivatePaneDirection, if the
current pane is zoomed, unzoom and then switch instead of doing nothing.
* Apply suggestions from code review
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
The issue seems to correlate with fractional pixels produced
by 0.5cell padding, so let's round down to avoid the fraction.
refs: https://github.com/wez/wezterm/issues/1228
Was mistakenly trying to use the windows font because of negative logic.
Tidy up, and prefer the gnome default theme font (Cantarell), but fall
back to DejaVu Sans.
This commit introduces the `Dimension` type which allows specifying
a value in a variety of units; pixels, points, cells, percent.
`Dimension` needs contextual information to be evaluated as pixel
values, which makes resolving the value from the config slightly
more of a chore.
However, this type allows more flexible configurations that scale
with the font size and display dpi.
refs: #1124, #291, #195
Avoid accidentally scaling the tab bar when using IncreaseFontSize.
Use a "better" default title font based on the platform.
Avoid a gap between bottom of tab button and dividing line at
certain font sizes.
`use_fancy_tab_bar` switches to an alternate rendering of the tab
bar that uses the window_frame config to get a proportional
title font to use to render tabs, as well as rendering a few
additional elements to space out and make the tabs feel more
like tabs.
Computing the number of tabs doesn't respect the alternate font
at this time.
Formatted tab item foreground and background colors are also
not respected at this time.
refs: #1180
* Trigger a paint immediately from invalidate if not throttled
* Otherwise defer the other events until we're about to sleep for xcb
events, which should maximize the coalesce around resize/expose events
refs: #1051
This makes the comparison in https://github.com/wez/wezterm/issues/544
work for me on mac, linux (x11, wayland) and also on Windows but
only using WGL.
It looks like we can use the proper colorspace on all targets
except for ANGLE EGL. For whatever reason, the combination of
glium and ANGLE EGL on windows over-gamma corrects.
AFAICT, the framebuffer and perhaps the surfaces it creates
don't indicate srgb support, and whatever combination of status
they return tickles glium's srgb stuff the wrong way.
I think the "solution" is just to directly use WGL by default.
EGL was on by default because it tended to be more survivable
when graphics card drivers were updated, but the last couple
of times I updated mine it still killed wezterm anyway.
refs: #544
This size seems to be ~sweet spot for `time cat bigfile`, cutting the
time in half from the prior value. Making the buffer smaller doesn't
improve things, nor does making it bigger; this is balancing the latency
of applying the update to the model with the back-pressured parsing
latency.
I'm not sure if this is needed now that we have a single draw call, but
based on the history and the nuance of different gl/driver/os quirks it
feels like a good idea to keep this option in the back pocket.
Previously, we'd use a 1MB buffer both to read the output from the
associated pty (blocking), and the same size buffer again to do the
non-blocking read on top of that.
For pathological cases (eg: cat 100MB+ files), we could build a
resulting `Vec<Action>` with over 1mm entries and it could take as much
as 100ms to apply those actions to the terminal model.
This meant that the output could stutter/lag and appear to be processed
more slowly.
This commit introduces a configuration value for the buffer size for the
second stage, and makes it 10KB in size. This helps to constrain the
size of the Action vec and keeps the incremental processing costs down,
while still managing the same throughput.
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.
It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.
refs: https://github.com/wez/wezterm/issues/894
refs: https://github.com/wez/wezterm/issues/806
This allows window-level config overrides to apply
to panes contained within the window.
For instance, this allows setting a window-level
color scheme.
I added this originally thinking that it would make it easier to resolve
https://github.com/wez/wezterm/issues/695 and to integrate wgpu support,
but it's the cause of https://github.com/wez/wezterm/issues/922 so let's
take it out and more directly connect the window events to those in the
terminal.
This commit likely breaks mac and windows; pushing it so that I can
check it out and verify on those systems.
opentype allows a font to have a weight in the range 0-1000.
MacOS has its own concept of symbolic weight names and opentype
values that is a slightly different scale of boldness to Windows
and Linux.
That means that Medium could be a different range of opentype
weight values depending on the system.
To further complicate things, the font designer can name their
variant with any name they like and assign it an arbitrary
opentype weight value.
For the Operator Mono font, it has Book variant with opentype
weight 325 and a Light variant with an opentype weight of 300.
wezterm was considering these both to have `FontWeight::Light` because
that's how those values were bucketed, which results in amibiguity in
resolve the font and frustration in not being able to access one of the
variants.
This commit changes the `FontWeight` type to now hold the unambiguous
opentype weight value, and to define some symbolic aliases for
some specified weights.
When serializing, if the weight matches a symbolic alias, then that
name will be used in the canonical name (eg: as listed via ls-fonts).
Otherwise, the numeric value will be used.
When parsing the font configuration, wezterm will allow both symbolic
and numeric values.
This allows all of the Operator Mono variants to be referenced
unambiguously, although some variants have to be specified via the
numeric weight:
```
wezterm.font("Operator Mono", {weight=275, stretch="Normal", italic=false}) -- /Users/wez/.fonts/OperatorMono-XLight.otf, FontDirs
wezterm.font("Operator Mono", {weight="Light", stretch="Normal", italic=false}) -- /Users/wez/.fonts/OperatorMono-Light.otf, FontDirs
wezterm.font("Operator Mono", {weight=325, stretch="Normal", italic=false}) -- /Users/wez/.fonts/OperatorMono-Book.otf, FontDirs
wezterm.font("Operator Mono", {weight="DemiLight", stretch="Normal", italic=false}) -- /Users/wez/.fonts/OperatorMono-Medium.otf, FontDirs
wezterm.font("Operator Mono", {weight="Regular", stretch="Normal", italic=false}) -- /Users/wez/.fonts/OperatorMono-Bold.otf, FontDirs
```
https://github.com/wez/wezterm/issues/849#issuecomment-873454483
This simplifies it a bit and exposes the config via the config file;
the following options are possible, each one specifies a color
```lua
return {
window_frame = {
inactive_titlebar_bg = "",
active_titlebar_bg = "",
inactive_titlebar_fg = "",
active_titlebar_fg = "",
inactive_titlebar_border_bottom = "",
active_titlebar_border_bottom = "",
button_fg = "",
button_bg = "",
button_hover_fg = "",
button_hover_bg = "",
}
}
```
refs: https://github.com/wez/wezterm/issues/761
Adds a `ShowDebugOverlay` key assignment that will create a tab
overlay that shows a limited number of recently logged events.
refs: https://github.com/wez/wezterm/issues/641
This commit introduces the knowledge about whether a font is
scalable or was using bitmap strikes (eg: color emoji bitmaps).
Then that information is used to help figure out whether and
how to scale a glyph.
refs: https://github.com/wez/wezterm/issues/685
Previously, we used `git describe --tags` to produce a version number
for non-released builds derived from the most recent tag + some info
such as the number of commits since that tag and then `g{HASH}`.
That always confuses people because the date portion at the front
looks old (it is typically the previous release) and the hash at
the end has that `g` in it.
This commit simplifies both the tag name used when making a release
and the computed version number take the date/time from the current
commit, and then append the hash. That way the version number always
corresponds to a commit.
This scheme doesn't help detect situations where the commit is
dirty, but I don't think the old one would have helped with that
either.
* Make alphabet and patterns configurable
* add docs
* Enhance scrollback search to support regex captures so that
searching for eg: `fo(o)` will select the last `o` in `foo`.
refs: https://github.com/wez/wezterm/issues/732
This is the first pass implementation, drawing on the alphabet logic
and default patterns from tmux-thumbs (thanks @fcsonline!).
ctrl-shift-space pops up the quick select overlay.
Typing the highlighted prefix will select the matching text and
copy it as though the `Copy` key assignment was used.
TODOs are to make the alphabet and patterns configurable, as well
as write up some docs.
refs: #732
This tidies up how we pass the ssh config to the connection ui
logic, by moving the ssh_config setup to the two callers.
A couple of notable adjustments:
* SshDomain::username is now optional; it will default to the
values computed by the ssh config file loader
* no_agent_auth value wasn't hooked up to anything, but now it is
refs: https://github.com/wez/wezterm/issues/730
Now that all platforms know whether the system fallbacks
covered the requested glyph range, it is reasonable to
restore the configuration error window to advise the user
if they are missing fonts for the text they want to display.
refs: https://github.com/wez/wezterm/issues/671
One of the default key assignments was registered as `SUPER+SHIFT+{`
which worked on macOS, but on Linux, would never match because the
keypress over there was (correctly) reporting as `SUPER+{`.
I originally thought that the user reported issue was a linux
normalization problem, but in looking deeper, the issue is really
that macos is doing something funky!
On macos we collect the interpreted key event as a string, and also
the interpretation of that event without any modifiers applied.
For letters this means that eg: `ALT-l` reports as `¬` for the
processed string and `l` for the unmodified string. That's good!
However, for punctuation we get a backwards result: SUPER+SHIFT+[
produces `[` for the processed text and `{` for the unmodified
text!
This commit tries to detect this, using a heuristic that is
potentially bad on non-US layouts: if both the processed and
unmodified strings are punctuation then we bias to the unmodified
version.
With that change, that key press is correctly reported as `SUPER+{`,
and we can fix the key assignment registration to reflect that.
I quickly checked the behavior of pressing that same physical key
combination with a DEU layout active, and it appears that the unmodified
stuff is also flipped there; we get a lower-case version of something
that I think should be uppercase. This commit doesn't change that
behavior:
```
key_event KeyEvent { key: Char('ü'), modifiers: NONE,
raw_key: Some(Char('Ü')),
raw_modifiers: SHIFT | SUPER,
raw_code: Some(33),
repeat_count: 1, key_is_down: true }
```
refs: https://github.com/wez/wezterm/issues/601
This replicates `last-window` in tmux. To pull this off, I
deliberately store the last tab whenever I'm activating a new one or
spawning a new one. I had to do this explicitly rather than hooking
set_active, because we end up setting the active tab briefly for some
common operations like moving a tab.
Default `allow_square_glyphs_to_overflow_width="WhenFollowedBySpace"`,
and expand its meaning from mostly square glyphs to glyphs that are
also wider than they are tall.
refs: https://github.com/wez/wezterm/issues/565
CI got broken by the termwiz release. This commit teaches the
various `git describe --tags` calls to filter to the wezterm
tags which all start with the year. We're match `20*` which should
be good for the next 79 years.
I've removed the vergen dependency as there was no way to teach it
to do the equivalent matching, and it wasn't a terrible burden
to just inline the git describe call anyway.
The previous behavior was to always treat ctrl-alt as altgr on Windows,
this has been done to better support altgr through a VNC session,
but this is very unintuitive when you don't need this behavior.
ref: #472
I'm calling it a temporary defeat on the shaping changes;
this commit effectively reverts the series of changes made
to support slicing up ligatures like `->` when the cursor
moves through them.
They've introduced so many issues and I've spent hours
that haven't resulted in a complete solution, so I've
disabled those changes by putting them behind a boolean
option.
I'll revisit them after I've cut the next release.
refs: https://github.com/wez/wezterm/issues/478
Queries the system battery information and returns an array of
battery information.
Each element is a lua table with the following entries:
* state_of_charge: expressed as percents
* vendor: the battery manufacturer
* model: the battery model
* serial: the battery serial number
* time_to_full: how long until the battery is full
* time_to_empty: how long until the battery is empty
* state: "Charging", "Discharging", "Empty", "Full", "Unknown"
I haven't run this on a system with a battery yet, so I'm holding
off from showing an example until I've got a work one.
refs: https://github.com/wez/wezterm/issues/500
As explained in the docs included in this commit, ideally this
wouldn't be needed, but due to a long-standing hinting bug in
freetype <https://gitlab.freedesktop.org/freetype/freetype/-/issues/761>
it seems most expedient to just render our own block glyphs,
so that's what this does!
refs: #433
This commit expands on the prior commits to introduce the concept
of per-window configuration overrides.
Each TermWindow maintains json compatible object value holding
a map of config key -> config value overrides.
When the window notices that the config has changed, the config
file is loaded, the CLI overrides (if any) are applied, and then
finally the per-window overrides, before attempting to coerce
the resultant lua value into a Config object.
This mechanism has some important constraints:
* Only data can be assigned to the overrides. Closures or special
lua userdata object handles are not permitted. This is because
the lifetime of those objects is tied to the lua context in which
they were parsed, which doesn't really exist in the context of
the window.
* Only simple keys are supported for the per-window overrides.
That means that trying to override a very specific field of
a deeply structured value (eg: something like `font_rules[1].italic = false`
isn't able to be expressed in this scheme. Instead, you would
need to assign the entire `font_rules` key. I don't anticipate
this being a common desire at this time; if more advance manipulations
are required, then I have some thoughts on an event where arbitrary
lua modifications can be applied.
The implementation details are fairly straight-forward, but in testing
the two examplary use cases I noticed that some hangovers from
supporting overrides for a couple of font related options meant that the
window-specific config wasn't being honored. I've removed the code that
handled those overrides in favor of the newer more general CLI option
override support, and threaded the config through to the font code.
closes: #469closes: #329
`wezterm`, `wezterm-gui` and `wezterm-mux-server` now all support
a new `--config name=value` CLI option that can be specified
multiple times to supply config overrides.
Since there isn't a simple, direct way to update arbitrary fields
of a struct in Rust (there's no runtime reflection), we do this
work in lua.
The config file returns a config table. Before that is mapped
to the Rust Config type, we have a new phase that takes each
of the `--config` values and applies it to the config table.
For example, you can think of configuration as working like this
if wezterm is started as `wezterm --config foo="bar"`:
```lua
config = load_config_file();
config.foo = "bar";
return config;
```
The `--config name=value` option is split into `name` and `value`
parts. The name part is literally concatenated with `config` in
the generated lua code, so the name MUST be valid in that context.
The `value` portion is literally inserted verbatim as the rvalue in the
assignment. Not quoting or other processing is done, which means
that you can (and must!) use the same form that you would use in
the config file for the RHS. Strings must be quoted. This allows
you to use more complicated expressions on the right hand side,
such as:
```
wezterm --config 'font=wezterm.font("Fira Code")'
```
The overrides stick for the lifetime of the process; even if
you change the config file and reload, then the value specified
by the override will take precedence.
refs: https://github.com/wez/wezterm/issues/469
refs: https://github.com/wez/wezterm/issues/499
`exit_behavior = "Hold"` will keep the pane alive until explicitly
closed. More details in the docs that are part of this commit.
refs: https://github.com/wez/wezterm/issues/499
This function is intended to deal with certain kinds of ligatures
and certain combining sequences that don't have corresponding glyphs.
It isn't hooked up to the gui yet, but does have unit tests that
are probably mostly correct.
refs: https://github.com/wez/wezterm/issues/478
In the earlier times wezterm supported different font rasterizers,
and the configuration was a bit vague and generic to accomodate
differences in how the rasterizers worked.
Since then, we've standardized on freetype.
One of the things that's been bothering me for a while is that
we have some fiddly logic to transform from the config to the freetype
flags.
This commit does away with the transformation and simply exposes
the two sets of freetype options.
The main thing that I expect people to play with is
`freetype_load_target` which can have one of the following values:
```
pub enum FreeTypeLoadTarget {
/// This corresponds to the default hinting algorithm, optimized
for standard gray-level rendering.
Normal,
/// A lighter hinting algorithm for non-monochrome modes. Many
generated glyphs are more fuzzy but better resemble its original
shape. A bit like rendering on Mac OS X. This target implies
FT_LOAD_FORCE_AUTOHINT.
Light,
/// Strong hinting algorithm that should only be used for
monochrome output. The result is probably unpleasant if the glyph
is rendered in non-monochrome modes.
Mono,
/// A variant of Normal optimized for horizontally decimated LCD displays.
HorizontalLcd,
/// A variant of Normal optimized for vertically decimated LCD displays.
VerticalLcd,
}
```
I expect most people will want to set this to one of `Normal`, `Light`
or `HorizontalLcd`. `HorizontalLcd` is what `font_antialias=Subpixel`
used to select.
refs: #491
This allows explicitly manipulating the hue, saturation, brightness
of the text rendered in the terminal, allowing users to dial in
the accidental effect that was introduced by
d886de8300
For example, this will punch up the brightness:
```
foreground_text_hsb = {
hue = 1.0,
saturation = 1.0,
brightness = 1.5,
},
```
refs: https://github.com/wez/wezterm/issues/491
* Add cli option --config-file
* Update cli arg doc & make it conflict with skipping config
* When the config is given explicitly (either using --config-file or via WEZTERM_CONFIG_FILE), failing to load this file will use the default config.
* Otherwise the config file is searched one by one in a few directories.
This commit changes mouse-based selection and middle click to use the
PrimarySelection.
CTRL-SHIFT-{C,V} use Clipboard.
{SHIFT,CTRL}-Insert use PrimarySelection.
`CompleteSelection` and `CompleteSelectionOrOpenLinkAtMouseCursor` now
require a parameter to specify the destination clipboard.
Removed the `default_clipboard_XXX` options added in
8dad34fa61 in favor of just explicitly
assigning the key/mouse bindings.
closes: #417
* Adds `CopyTo` and `PasteFrom` assignments that specify the
destination/source.
* Adds `default_clipboard_copy_destination` and `default_paste_source`
config options that specify the default destination/source for
existing `Copy` and `Paste` operations (for @bew)
* Deprecating `PastePrimarySelection` in favor of `PasteFrom`.
* Added `CTRL-Insert` -> `Copy` (for @Babar)
Aside from the new key assignment, these changes shouldn't change
the default behavior, but do make it easier to consider changing
that in a later commit.
They should allow for example:
* Set `default_clipboard_copy_destination = "PrimarySelection"` to
prevent populating the clipboard by default when using the mouse.
* Overriding the CTRL-Insert, CTRL-SHIFT-C to explicitly populate
the clipboard
* Set `default_paste_source = "PrimarySelection"` for middle click
to paste the selection.
* Overriding SHIFT-Insert, CTRL-SHIFT-V to explicitly paste from
the clipboard.
refs: #417
* Add config option to specify default current working directory
* Make `cwd` of CLI take precedence over `default_cwd`
* Update docs for `default_cwd` and Launching Programs
Explains the `default_cwd` property more succinctly on the `Config` struct.
Adds documentation on the various ways to set the working directory and the logic used to decide the working directory.
* Add ClearBuffer action
Clears all lines, both visible and those scrolled off the top of the viewport, making the prompt line the new first line and resetting the scrollbar thumb to the full height of the window.
This is the behavior that Hyper / xterm has for clearing the terminal.
* Combine ClearBuffer into ClearScrollback as enum with associated erase mode
Makes it easier to manage the different options of clearing the terminal.
The default is true, which means that adjusting the font size will
cause the window to resize to preserve the number of rows/cols in
the terminal.
When set to false, the window size is preserved and the number of
terminal rows/cols is adjusted instead.
refs: https://github.com/wez/wezterm/issues/431
wezterm sets a more restrictive umask (`0o077`) by default so that any files
that it creates (eg: unix domain socket, log files) are more secure
by default.
However, some environments rely on the more general default of (`0o022`)
without checking that it is set.
This matters because programs spawned by wezterm inherit its more
restricted umask.
I hadn't noticed this because I've had `umask 022` in my shell RC files
since sometime in the 1990's.
This commit adds some plumbing to the pty layer to specify an optional
umask for the child process, and some more to our umask saver helper
so that any thread can determine the saved umask without needing a
reference to the saver itself, which may be in a different crate.
The logic in the config crate has been adjusted to connect the saved
value to the default command builder arguments.
The net result of this is that running `wezterm -n start bash -- --norc`
and typing `umask` in the resultant window now prints `0022`.
refs: #416
When running the GUI, we generate a unix domain socket path for
the current process and start up a mux server for that path.
This allows `wezterm cli list` and `wezterm cli split-pane` to
work implicitly inside the GUI session.
When started in this way, the mux server is not persistent;
when the GUI process is terminated, all of its windows, tabs
and panes are terminated.
refs: https://github.com/wez/wezterm/issues/230
The new banner is less intrusive; it doesn't steal focus
and for users that have multiple wezterm processes, doesn't show
one per process.
So let's turn off the updater window. I'm considering moving the
"smart" upgrade links into a helper subcommand, but that's for
another diff.
61c52af491 accidentally broke key
assignments that included ALT on macOS (and perhaps others?) because
LEFT_ALT or RIGHT_ALT were also now being passed through to the
keymap lookup, preventing a direct match.
This defaults to None, taking the default from the freetype library.
You can select an integer value to tell the library to use an
alternative version.
Versions that are available in the build used by wezterm are 35, 38 and
40.
See https://freetype.org/freetype2/docs/subpixel-hinting.html for
more information.
The default is 1.0. `line_height` is used to scale the effective
cell height, increasing the amount of space between font baselines.
refs: https://github.com/wez/wezterm/discussions/387
This helps keep the config object a bit smaller and the trace logging
output less verbose.
We now memoize the effective palette in the config, which should shave
off a little bit of time in the renderer.
in ab342d9c46 I started to rearrange how
the output processing thread works. It wasn't quite right, so this
commit tidies things up.
The main change here is that there is now back-pressure from the output
parser on the reader; if it is taking a while to parse the output then
we don't buffer up so much input.
This makes operations like `find /` followed immediately by `CTRL-C`
more responsive.
With this change, I don't feel that the
`ratelimit_output_bytes_per_second` option is needed any more, so it
has been removed.
To avoid confusing behavior, normalize the configured keys
in the same way that we normalize key presses.
In other words, this:
```lua
{
key = "y",
mods = "CTRL|SHIFT",
action = "Copy",
}
```
is treated as if you wrote:
```lua
{
key = "Y",
mods = "CTRL",
action = "Copy",
}
```
refs: https://github.com/wez/wezterm/issues/372
Teach the core text locator how to obtain the system fallback list
and add that to the fallback.
Fixup handling of ttc files on macOS; we'd always assume index 0
when extracting font info from the font descriptor. We now make
the effort to enumerate the contents of the TTC and find a match.
https://wiki.lazarus.freepascal.org/Cocoa_DPI states that the dpi
on macOS is 72. That matches up to the experimental results reported
in #332 (in which 74.0 appears about the right size).
This commit introduces a `DEFAULT_DPI` constant that is set to 72 on
macOS and 96 on other operating systems.
The result of this is that a 10 point Menlo font now appears to be
the same size in Terminal.app and WezTerm.app.
refs: https://github.com/wez/wezterm/issues/332
This commit is a bit noisy because it also meant flipping the key map
code from using the termwiz input types to the window input types, which
I thought I'd done some time ago, but clearly didn't.
This commit allows defining key assignments in terms of the underlying
operating system raw codes, if provided by the relevant layer in the
window crate (currently, only X11/Wayland).
The raw codes are inherently OS/Machine/Hardware dependent; they are the
rawest value that we have available and there is no meaningful
understanding that we can perform in code to understand what that key
is.
One useful property of the raw code is that, because it hasn't gone
through any OS level keymapping processing, its value reflects its
physical position on the keyboard, allowing you to map keys by position
rather than by value. That's useful if you use software to implement
eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of
your key bindings.
New config option:
`debug_key_events = true` will cause wezterm to log an "error" to stderr
each time you press a key and show the details in the key event:
```
2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true }
```
This is useful if you want to figure out the `raw_code` for a key in your
setup.
In your config, you can use this information to setup new key bindings.
The motivating example for me is that because `raw_key` (the unmodified
equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key
assignment doesn't function for me on Linux, but I can now "fix" this in
my local configuration, taking care to make it linux specific:
```lua
local wezterm = require 'wezterm';
local keys = {}
if wezterm.target_triple == "x86_64-unknown-linux-gnu" then
local tab_no = 0
-- raw codes 10 through 19 correspond to the number key 1-9 positions
-- on my keyboard on my linux system. They may be different on
-- your system!
for i = 10, 20 do
table.insert(keys, {
key="raw:"..tostring(i),
mods="CTRL|SHIFT",
action=wezterm.action{ActivateTab=tab_no},
})
tab_no = tab_no + 1
end
end
return {
keys = keys,
}
```
Notice that the key assignment accepts encoding a raw key code using
a value like `key="raw:11"` to indicate that you want a `raw_code` of
`11` to match your key assignment. The `raw_modifiers` portion of
the `KeyEvent` is used together with the `raw_code` when deciding
the key assignment.
cc: @bew
Adds an option to control how wide glyphs (more specifically: square
aspect glyphs) are scaled to conform to their specified width.
The three options are `Never`, `Always`, and `WhenFollowedBySpace`.
When a glyph is loaded, if it is approximately square, this option is
consulted. If overflow is permitted then the glyph will be scaled
to fit only the height of the cell, rather than ensuring that it fits
in both the height and width of the cell.
refs: #342
Make an effort to explain what failed to load and where it came from,
and funnel users to the documentation on font configuration.
The message presented is slightly different depending on whether
we think that the font was their primary font, an explicitly
specified font_rule or an implicitly synthesized font_rule.
refs: #340
Bundle the *Last Resort High-Efficiency* font from
https://github.com/unicode-org/last-resort-font/
version 13.001 (Oct 22 2020).
This provides a more useful fallback glyph than we'd otherwise
produce if there is no matching glyph in any of the fonts.
Its license is OFL-1.1 which is compatible with the other
bundled fonts.
There are a number of cases where font-loader might panic on windows,
and the optional font-loader dep causes problems with `cargo vendor`
in #337, so this is a step to removing that dep.
This commit makes direct GDI calls to enumerate monospace truetype
fonts from the system and then applies our normal matching on the
result.
This makes it possible to configure wezterm to eg: triple click
on command input (or output) to select the entire input or output
without messing around trying to find the bounds.
The docs have an example of how to configure this; it requires
setting up shell integration to define the appropriate semantic
zones.
Adds some supporting methods for computing the `SemanticZone`s
in the display and a key assignment that allows scrolling the
viewport to jump to the next/prev Prompt zone.
This wasn't used by anything and the version was getting pretty stale.
Upgrading is awkward because newer versions pull in an incompatible
freetype library version.
This commit revises the opacity configuration to make it more
consistently applied.
* `window_background_opacity` controls the overall window capacity,
whether a background image is present or not.
* When a background image is present, or if the window is transparent,
then text whose background color is the default background is
changed to have a fully transparent background.
* `text_background_opacity` controls the alpha channel value for
text whose background color is NOT the default background.
It defaults to 1.0 (fully opaque), but can be set to be
transparent by setting it to a number between 0.0 and 1.0.
* The inactive pane hue, saturation, brightness multipliers
have been factored out into their own struct which changes
that set of options to:
```lua
return {
inactive_pane_hsb = {
hue = 1.0,
saturation = 1.0,
brightness = 1.0,
},
}
```
* `window_background_image_hsb` is a new option that can apply
a hue, saturation, brightness transformation to a background
image. This is primarily useful to make a background image
darker:
```lua
return {
window_background_image = "/some/pic.png",
window_background_image_hsb = {
brightness = 0.3,
},
}
```
refs: #302
refs: #297
Upcoming changes to the GUI mean that it will be double
the work to keep maintaining this, and it is already lagging
behind on pane support.
With the Mesa llvmpipe fallback we should be in a pretty
good state to not need another non-GL implementation.
I thought it would be cute to add an option to add a background image to
the window.
While playing around with the parameters, I accidentally implemented
window transparency on X11/Wayland, provided that you have a compositing
window manager. I don't know of the transparency also works on macOS or
Windows as of yet; will try that out once I push this commit.
This commit introduces three new configuration options explained below.
In the future I'd like to allow specifying equivalent settings in a
color scheme, and then that would allow setting per-pane background
images.
```lua
return {
--[[
Specifies the path to a background image attachment file.
The file can be any image format that the rust `image`
crate is able to identify and load.
A window background image is rendered into the background
of the window before any other content.
The image will be scaled to fit the window.
If the path is not absolute, then it will taken as being
relative to the directory containing wezterm.lua.
]]
window_background_image = "/some/file",
--[[ Specifies the alpha value to use when rendering the background
of the window. The background is taken either from the
window_background_image, or if there is none, the background
color of the cell in the current position.
The default is 1.0 which is 100% opaque. Setting it to a number
between 0.0 and 1.0 will allow for the screen behind the window
to "shine through" to varying degrees.
This only works on systems with a compositing window manager.
Setting opacity to a value other than 1.0 can impact render
performance.
]]
window_background_opacity = 1.0,
--[[
Specifies the alpha value to use when applying the default
background color in a cell. This is useful to apply a kind
of "tint" to the background image if either window_background_image
or window_background_opacity are in used.
It can be a number between 0.0 and 1.0.
The default is 0.0
Larger numbers increase the amount of the color scheme's
background color that is applied over the background image.
This can be useful to increase effective contrast for text
that is rendered over the top.
]]
window_background_tint = 0.0,
}
```
refs: https://github.com/wez/wezterm/issues/141
This is similar in spirit to the work in 4d71a7913a
but for Windows.
This commit adds ANGLE binaries built from
07ea804e62
to the repo. The build and packaging will copy those into the same
directory as wezterm.exe so that they can be resolved at runtime.
By default, `prefer_egl = true`, which will cause the window
crate to first try to load an EGL implementation. If that fails,
or if `prefer_egl = false`, then the window crate will perform
the usual WGL initialization.
The practical effect of this change is that Direct3D11 is used for the
underlying render, which avoids problematic OpenGL drivers and means
that the process can survive graphics drivers being updated.
It may also increase the chances that the GPU will really be used
in an RDP session rather than the pessimised use of the software
renderer.
The one downside that I've noticed is that the resize behavior feels a
little janky in comparison to WGL (frames can render with mismatched
surface/window sizes which makes the window contents feel like they're
zooming/rippling slightly as the window is live resized). I think this
is specific to the ANGLE D3D implementation as EGL on other platforms
feels more solid.
I'm a little on the fence about making this the default; I think
it makes sense to prefer something that won't quit unexpectedly
while a software update is in progress, so that's a strong plus
in favor of EGL as the default, but I'm not sure how much the
resize wobble is going to set people off.
If you prefer WGL and are fine with the risk of a drive update
killing wezterm, then you can set this in your config:
```lua
return {
prefer_egl = false,
}
```
refs: https://github.com/wez/wezterm/issues/265
closes: https://github.com/wez/wezterm/issues/156
This changes the ALT/dead key behavior a little bit more,
and in a way that is likely more useful to terminal users.
The default behavior is that system dead key processing is enabled.
For example, with DEU keyboard layout activated:
* `^` `<SPACE>` results in a single `^`
* `^` `e` result in those two characters combining into an e with a
diacritic.
If the config sets `use_dead_keys = false` then the behavior changes;
wezterm probes the active keymap to determine which keys are marked
as dead keys and computes their single character expansion. When
the dead key is pressed then that expansion is substituted instead.
So `^` is simply `^`.
In order to pull this off, the window layer needs to selectively
call `TranslateMessage` for the system dead key expansion case
instead of unconditionally in the global message loop.
As a result of *that*, it means that we don't perform the default ALT
key translation for every key press any more. I looked to see how old
friend putty handles this and found that it only allows default system
processing for ALT-space and ALT-F4. I was resistent to selectively
processing system shortcuts because the full set are effectively
unknowable to an application and I didn't want to try to replicate
a wide selection of varying keypresses. I'm fine to only allow
these two, so this commit does that, and reverts the portion of
the prior commit that prevented passing general ALT key combinations
through.
refs: #275
refs: #296
This commit teaches the config layer to distinguish between
explicitly configured fonts and automatic fallback fonts.
Font loading now maintains the set of loaded fonts. If after
loading from all configured sources a non-fallback font is
not present in the loaded set, wezterm will now pop up the
configuration error window to explain what is happening.
closes: #263
This will delay for the specified number of milliseconds.
This is an async function; it won't block the gui thread,
it will deschedule running the script and resume it once
the timeout has expired.
refs: #222
This commit adds very basic first passes at representing the Pane
and GuiWindow types in lua script.
The `open-uri` event from 9397f2a2db
has been redefined to receive `(window, pane, uri)` parameters
instead of its prior very basic `uri` parameter.
A new key assignment `wezterm.action{EmitEvent="event-name"}` is
now available that allows a key binding assignment to emit an arbitrary
event, which in turn allows for triggering an arbitrary lua callback
in response to a key or mouse click.
`EmitEvent` passes the `(window, pane)` from the triggering window and
pane as parameters.
Here's a brief example:
```lua
local wezterm = require 'wezterm';
wezterm.on("my-thingy", function(window, pane)
local dims = pane:get_dimensions();
wezterm.log_error("did my thingy with window " .. window:window_id() ..
" pane " .. pane:pane_id() .. " " .. dims.cols .. "x" .. dims.viewport_rows);
window:perform_action("IncreaseFontSize", pane);
end)
return {
keys = {
{key="E", mods="CTRL", action=wezterm.action{EmitEvent="my-thingy"}},
}
}
```
refs: #223
refs: #225
This builds on the new lua event handler plumbing added
in ccea650a93 to co-opt
the default URI opening action:
```lua
wezterm.on("open-uri", function(uri)
if uri:find("jira") then
wezterm.log_error("do something with jira")
wezterm.run_child_process({
"wezterm",
"start",
"--",
"jira",
"view",
extract_task_from_uri(uri)
})
-- prevent the default action from opening in a browser
return false
else
-- log but allow the uri to be opened in the browser
wezterm.log_error("clicken " .. uri)
end
end)
```
This doesn't allow exactly the sketched out option from
issue #223 to be implemented, but may be close enough
to be useful.
refs: #223
refs: #225
