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.
