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
I'm not sure what exactly changed (perhaps it was a Windows updated?)
but window_background_opacity was only taking effect for windows
with no title bar.
I found that explicitly configuring a region makes transparency
work again.
refs: #553
terminus-bold.otb reports 0 height!
Detect and force that case to go through the bitmap strike loading
code path.
Improve the size selection heuristic for bitmap strikes: previously,
we would just pick the largest bitmap and allow it to be scaled down,
which was OK for emoji fonts that just had 128px square glyphs, but
is not ok for pre-rendered pixel strikes like terminus.
Note that IncreaseFontSize works in terms of percentages only,
so using a font like this may have "gaps" when ctrl-+ or - to change
the font size.
refs: https://github.com/wez/wezterm/issues/560
This is first draft; the animation rate is currently tied
to the cursor_blink_rate setting, so if the gif has frames that
are intended to display more frequently than that, they will
animate more slowly.
Animation is only carried out while the window has focus.
Animation increases the load on the GPU and thus uses more power.
It's kinda fun to stick one of these animated pixel gifs in the background:
https://imgur.com/gallery/F9DAH
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
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
This is defined as a trait method on Pane (default: false), and has the
obvious transitive equivalent methods in Tab and Window (eg: if all
contained items are `can_close_without_prompting`, then that container
is also `can_close_without_prompting`).
The intent is to avoid bothering the user to confirm closing a window
when the content is not stateful and doesn't warrant it.
For example: the window that is displayed in the event of a
configuration error really shouldn't prompt to the user to confirm
closing it.
All termwiztermtab panes are `can_close_without_prompting==true`
to effect this policy.
In the future, we could teach LocalPane to lookup the session leader
process against a list of "uninteresting" or "stateless" processes
and return an appropriate result (as suggested in
https://github.com/wez/wezterm/issues/280). That functionality
is NOT part of this commit.
`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 fixes a longstanding issue under mutter where client side
decorations are in use. The decorations were being drawn too
early in the initialization of the window which could leave them
off-screen and weird. This was masked by a couple of mutter
related bugs with client side decorations.
With these changes I now get sane decorations under mutter,
and the toggle fullscreen action is now enabled as well!
closes: #224
We weren't didn't treat the "No existing hyperlink, No new hyperlink"
case as no change in hyperlink, and were invalidating the window on
every mouse except for those over text with a hyperlink.
Pasting a lot of text could cause a deadlock between writing
to the input side of the pty and consuming the output side.
Making the writer/input side non-blocking resolves this.
Dead key processing respects the
`send_composed_key_when_left_alt_is_pressed` and
`send_composed_key_when_right_alt_is_pressed` options.
See doc changes included in this commit for more info.
refs: https://github.com/wez/wezterm/issues/410
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
I started this a while ago; it's pretty time consuming to produce
accessible and usable documentation for this sort of stuff, so
this isn't yet complete, but in the interest of avoiding additional
bit-rot, let's get this up.
refs: https://github.com/wez/wezterm/issues/257
The heart of this issue was that the resize callbacks have two
layers of state; one in the low level window and one in the application
level window.
On Windows, the system triggers the low level callback prior to
opengl being initialized. Since the application level depends on
the opengl state, there are some code paths where it NOPs and
returns early if opengl isn't yet initialized.
When the system-wide display scaling is set to say 200%, the application
layer can't know the effective DPI of the window it is creating because
it doesn't know which monitor will be used or what its DPI will be.
New windows are created at the default DPI of 96, and we rely on the
resize events to detect the actual DPI and adjust the scaling in
the window.
The early call of the resize callback meant that the low level and
application level size/dpi state was out of sync and the result was
that the window had half as many pixels as it should, but that the
terminal model was still sized as though it had the correct amount
(twice as many as visible). This resulted in the window being too
small for the viewport.
The resolution is simple: we now suppress emitting the resize processing
until opengl has been initialized.
The test scenario for this is:
* Set system scaling to 100%
* Launch wezterm
* Set system scaling to 200%
* Observe that wezterm scales to match
* Press CTRL-SHIFT-N to spawn a new window
* Observe that the new window size matches the other window (previously
this one would be half the size)
While I was looking at this, I noticed that the manifest didn't
match the DPI awareness that we have in the code, so update that.
refs: https://github.com/wez/wezterm/issues/427
This appears to have been broken since the introduction of mouse
assignments :-/
This commit adds Pane::is_alt_screen_active so that the gui layer
can tell whether the alt screen is active, and allow passing down
the event.
refs: #429
This persuades the CI to install both the arm and intel flavors
of the rust toolchain on macOS, and the deploy script to generate
a universal binary.
* need big sur to build for M1
* Use cross-compilation compatible mlua from my fork for now
I've seen a number of people copy and paste the example that runs
`top` and be confused by it, so try to make it a bit clearer how
to get a regular split with a shell inside it.
If a font doesn't have any latin glyphs then we'd compute 0 as the
average width. Later, during rendering, we'd compute an `inf` scaling
factor and then subsequently fail to allocate texture space.
This commit takes the average width from a "random" selection of glyphs
(whatever the first few glyphs in the font may be) to avoid that
situation.
refs: https://github.com/wez/wezterm/issues/404
I didn't recreate precisely the situation in the issue, but I
tried pressing both `AltGr 8` and `CTRL ALT 8` with a DEU
layout active and both now result in `[` being emitted.
refs: #392
80214319ae broke the use of RUST_LOG to
turn up trace logging.
This commit refactors logger initialization into the env-bootstrap crate
so that it is centralized, and adopts the use of `WEZTERM_LOG` to
override the default logging filters, rather than `RUST_LOG`.
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
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.
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 improves input processing on macOS; passing the keyUp
events to the input context is required for dead keys to correct
process their state transitions.
In addition, we weren't passing key events through if any modifiers
were down; for dead keys we need to allow Option through.
This commit rigs up a little bit of extra state to avoid double-emitting
key outputs from the input context.
Lastly, the virtual key code is passed through to the KeyEvent to
enable binding to raw keys per 61c52af491
refs: #357
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
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.
There were two problems:
* It was using an old code path that didn't even try to resolve the cwd
* The NewWindow code path would "forget" the originating window and then
fail to resolve the current pane + path from the new, empty window
that it is building.
closes: https://github.com/wez/wezterm/issues/322
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 avoids having a green (by default) border around the cursor.
The dynamic color escape sequences have been updated to also
change the border color when the cursor background color is changed.
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
This includes a script to generate a screenshot from a wezterm
running the default config under X11.
It expects the iTerm2-Color-Schemes to be checked out alongside
the wezterm repo as it uses the dynamic color schemes scripts
to activate the schemes one by one and capture the display.
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.
There's a few different knobs to turn, but this
commit turns them and we're now able to respect
opacity settings for both OpenGL/CGL and Metal
renderers.
closes: #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 commit adjusts the window layer to have it try to load EGL
implementations on macOS. This is important as the system
provided OpenGL implementation is deprecated and I wanted to
have a path forward for when it is finally removed.
If EGL fails to initialize, we fall back to the CGL/OpenGL
implementation that we used previously.
I've included binaries built for 64-bit intel from the MetalANGLE
project; here's how I built them:
```
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git --depth 1
git clone https://github.com/kakashidinho/metalangle --depth 1
cd metalangle
PATH=$PWD/../depot_tools:$PATH python scripts/bootstrap.py
PATH=$PWD/../depot_tools:$PATH gclient sync
PATH=$PWD/../depot_tools:$PATH gn --args="is_debug=false angle_enable_metal=true angle_enable_vulkan=false angle_enable_gl=false angle_build_all=false" gen out/Release
PATH=$PWD/../depot_tools:$PATH autoninja -C out/Release
```
Those steps are a little too long to want to put them directly
into the wezterm CI.
It is important for metalangle to be >= 8230df39a5
in order for scaling to be handled correctly when dragging windows
between monitors.
refs: https://github.com/kakashidinho/metalangle/issues/34
To reproduce the problem, maximize wezterm, then press CMD-N.
This commit tells the window not to use cocoa native tabs and
instead really create a new window when we ask it to create
a new window.
closes: #254
Moved the image and hyperlink portion of CellAttributes out
to a separate heap structure, saving 8 bytes per Cell
for the common case of no hyperlink and no image.
`wezterm.action{ExtendSelectionToMouseCursor=nil}` doesn't produce an
`ExtendSelectionToMouseCursor(None)` value because a table value of
`nil` is equivalent to that key not being present and lua sees just
an empty table.
Instead we need to accept `ExtendSelectionToMouseCursor={}` a valid
way to indicate an `Option::None` which is what this commit does.
Due to weirdness that I haven't had a chance to run down, passing
that value through `wezterm.action` doesn't produce the intended
value, so I'm adjusting the docs to show to specify an alternative
syntax for this as part of this commit.
refs: https://github.com/wez/wezterm/issues/282
This adds an extra level of indirection to the Mux model;
previously we allowed for Windows to contain an ordered
collection of Tabs, where each Tab represented some kind
of pty.
This change effectively renames the existing Tab trait to Pane
and introduces a new Tab container, so the new model is that
a Window contains an ordered collection of Tabs, and each Tab
can have a single optional Pane.
refs: https://github.com/wez/wezterm/issues/157
This could be reproduced via `wezterm connect localhost`.
This bug was surfaced after the last release added a Drop impl
to cleanup the display.
This commit tracks the display in the connection.
closes: https://github.com/wez/wezterm/issues/252
This commit adds an overline glyph which is simply a line drawn at
the top of the cell.
Due to the way that we use a single glyph for the line layer, this
actually adds a handful of combination glyphs for the different
underline, overline and strikethrough possibilities.
It's getting a bit hefty. Adding another similar attribute in
the future (eg: maybe wiggly underlines?) might prove to be too
much for the simple approach we have right now.
```bash
printf "\x1b[53moverline\x1b[0m\n"
```
This allows setting up shortcuts relative to the final tab in
a window, rather than always being relative to the first.
The default assignment for CTRL+SHIFT+9 is now `ActivateTab=-1`
as a convenient way to always reach the last tab.
refs: https://github.com/wez/wezterm/issues/228
We were unconditionally adding the encoded form of the modifier
mask (eg: appending `;1~` to the sequence) and not all apps know
how to interpret that.
refs: https://github.com/wez/wezterm/issues/227
This commit adds support for left/right margins and has been
tested against esctest, with a final status of:
```
309 tests passed, 239 known bugs
```
"known bugs" also includes unimplemented features; we have a
similar degree as iTerm2.
As of this commit, we now report as a vt520ish machine to DA1.
I confess to not having read enough of the relevant docs
to know whether this is totally righteous.
This commit allows distinguishing between left and right alt
modifiers at the window layer. So far only macos provides
this additional information.
Expand the logic that decides whether Alt should emit the
composed key or act as the raw key with the Alt modifier flag
set so that we can set that behavior separately for the left
and right modifiers on systems that support it, and use the
existing config for systems that don't support it.
The default settings for these flags is that Left Alt will
send the uncomposed key + Alt modifier while the Right Alt
will behave more like AltGr (which is typically on the RHS
of the keyboard) and send the composed key.
This gives more flexibility by default and hopefully matches
expectations a bit better.
refs: https://github.com/wez/wezterm/issues/216
This was originally intended to be swept in and dealt with as part of
adopting CSI-u (refs: https://github.com/wez/wezterm/issues/63) but the
default shift-space mapping is super irritating in vim (refs:
https://github.com/wez/wezterm/issues/126) so it got partially walked
back, but as a consequence we accidentally dropped the modifiers from
those keys (refs: https://github.com/wez/wezterm/issues/213 refs:
https://github.com/wez/wezterm/issues/214).
This commit restores the modifiers for that case.
In addition, since we now have a way to plumb configuration directly
into the term crate, this adds a config option to enable CSI-u for those
that want to use it.
Bound to CMD-K and CTRL+SHIFT-K by default. This also functions
while the output is filling up (eg: `find /` and hit the key binding
to keep pruning the scrollback).
closes: https://github.com/wez/wezterm/issues/194
Now that the toml file support is removed, we can directly
express the key actions as enum variants so remove this
intermediate type and use the enum directly.
* AppImage: Support looking for configuration in `WezTerm.AppImage.config` and
`WezTerm.AppImage.home` to support portable thumbdrive use of wezterm on
linux systems
* We now check the github releases section for updated stable releases and show
a simple UI to let you know about the update, with links to download/install
it. We don't automatically download the release: just make a small REST API
call to github. There is no data collection performed by the wezterm project
as part of this. We check once every 24 hours. You can set
`check_for_updates = false` in your config to disable this completely if
desired, or set `check_for_updates_interval_seconds` to an alternative update
interval.
* Added support for OSC 110-119 to reset dynamic colors, improving our support for Neovim.
* Change OSC rendering to use the long-form `ST` sequence `ESC \` rather than
the more convenient alternative `BEL` representation, which was not
recognized by Neovim when querying for color information.
* Fixed Shift-Tab key on X11 and Wayland
* WezTerm is now also available to Windows users via [Scoop](https://scoop.sh/)
This commit adds some helper functions that make it possible to
dynamically discover and add WSL distributions to the launcher
menu.
refs: https://github.com/wez/wezterm/issues/159
This is accessible by right-clicking on the `+` button in the tab bar
and switches to an overlay offering options to spawn tabs and attach
domains.
The intent is to allow the configuration file to expand this list of
options, and on Windows, to auto-populate with the various combinations
of `cmd`, `powershell`, `elevated` and available `wsl` instances, but
for the moment the main value of this feature is the ability to attach
domains that were not set to connect automatically at startup.
This makes things more convenient when launching wezterm via the
gui: it is awkward to have to set up shortcuts that run
`wezterm connect foo`, or to type in the full path to `wezterm` when
you might want to run that manually.
Now you can double-click the icon and right-click the `+` and attach
the domain. (cc: @rjwalsh)
The launcher is a good candidate for being implemented on top of
native context menus where available... but we don't have any
such API plumbed through the `window` crate, so all platforms
get the wonderful terminal based overlay menu right now.
refs: https://github.com/wez/wezterm/issues/159
Sometimes we race with the nightly build while it is deleting
and uploading artifacts.
Since they have stable names, just hard code those in the the
markdown.
This commit adds the ability to change the relative or absolute
position of a tab within its containing window through the
use of a key assignment.
We include a default assignment of CTRL+SHIFT+PageUp for moving
left and CTRL+SHIFT+PageDown for moving right.
Closes: https://github.com/wez/wezterm/issues/84
