The issue is that the pane was only removed from the tab when explicitly
closed, leaving it to be later detected and flushed.
However, in the meantime, when performing eg: cursor blink maintenance,
if the set of panes in the tab is empty then the window would close.
The resolution is to ask the mux (rather than the tab) to kill the pane,
so that the cascading closure of the tab causes the window's active
tab to reference the correct remaining tab.
refs: #890
This changes the fill_rect function over to use the zeno crate.
zeno allows describing a path and filling or stroking.
This commit doesn't strictly need that, but it sets things
up for more interesting custom glyphs in later commits.
refs: #584
refs: #588
Same vein as 8931afba5cee07ab12990f06c2ff34d6f8426b19; the auth
window could sometimes get stuck until an input event was sent
to it.
Wire up a mux event so that the window can close itself.
When the client connected to an empty remote mux, it would allocate an
empty window and then spawn a new tab into it.
Meanwhile, the authentication window would close and trigger a prune of
all empty windows, causing the in-flight spawn to fail because its
destination window was removed.
This commit defers window pruning while Activity is in progress;
the MuxWindowBuilder has an associated Activity count.
in the same vein as d657721163, the
increased idle loop means we need to be careful not to suppress
invalidation events.
In this case, overlays aren't from the window in the mux model,
so we'd ignore invalidations for those.
While looking at this I realized that we'd also do the same
for output being emitted in panes that were not the active pane,
so tidy that up.
in the same vein as d657721163
this commit introduces more assertive signalling from the remote
mux when a pane is closed so that the client can update.
As part of reducing the amount of regularly scheduled stuff wezterm
does in the background, this commit restructures how an empty mux
is detected; now when the mux prunes dead windows it will emit
an Empty event.
The Activity type will now schedule a prune when it is dropped,
which will clean up and trigger the Empty event.
refs: https://github.com/wez/wezterm/issues/770
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 got a bit broken by the fix for https://github.com/wez/wezterm/issues/714
since we can be handed a range of logical line fragments, we should
test each of them to find our matching result.
Also, improve the logic for constraining the length when looking
backwards.
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
* Better function for undercurl
* Setting lower alpha
* underline alpha in line-frag
* make undercurl alpha background independent
* Improved Shader
* Old Rasterization
Co-authored-by: Roland Fredenhagen <git@modprog.de>
When the title, icon, OSC 7 and SetUserVars sequences are processed,
notify the embedding application.
The gui layer uses this to trigger a titlebar update.
refs: #647
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.
the binary search would falsely extend the end of the match
to the start of the subsequent match for the wrapped line case.
The resolution is to emit a coordinate for the newline that we
add to the haystack between the wrapped lines.
closes: https://github.com/wez/wezterm/issues/732
In the situation where we have a full screen terminal (eg: 500 cells
wide), but very little output (eg: only 10's of columns on the left are
NOT blank), we would previously spend a non-trivial amount of time
calculating fg/bg colors for the blanks that trailed the actual
clusters; the calculation for each row was:
O(trailing-blanks * full cell color compute cost)
which was around 30us per row. For large numbers of rows this could
add up to >10ms per frame.
This commit changes the logic to run in two phases:
* O(selection-width) with simple fg/bg color updates for the selection
range
* O(1) full cell color compute cost for the cursor if the cursor
is somehow in the trailing blank region and not already handled
by the earlier clustering logic.
With the sequence of recent commits, the frame time for the large
terminal case has been reduced from ~22ms to ~7ms, which is approx 3x
improvement.
refs: #740
It looks like the mux search results include a trailing newline
in some cases, which means that a match can wrap onto a second
line.
If that line is shorter than the label length, we could panic.
This commit makes quickselect safer to use in this situation,
but the real fix is with the mux search code.
It's not perfect; this only handles the case where you move down
into the terminal. I couldn't easily make the same thing happen
when moving the mouse up or left outside of the window. It's
probably fixable but this is better than it was.
closes: https://github.com/wez/wezterm/issues/591
* 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
I've built this on linux, which doesn't respect the timeout.
I've made speculative changes that should build on mac and windows,
but that don't plumb the timeout functionality on those systems
as of yet.
refs: #619
back out the portion of the cap height scaling that applied when
we knew the cap height of the primary font but not a fallback font.
That logic allowed some overly wide powerline fonts to be sized
correctly (a bit smaller), but also meant that a number of emoji
and other symbol glyphs were now undersized.
refs: https://github.com/wez/wezterm/issues/727
It now outputs something that you could conceivably put into
your config file, although the intent is to show the canonical
way to reference the individual fonts that were found, rather
than to specify a fully baked list to paste into a config.
eg:
```
; ./target/debug/wezterm ls-fonts
Primary font:
wezterm.font_with_fallback({
-- /home/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
{family="Operator Mono SSm Lig", weight="DemiLight"},
-- /home/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontConfig
{family="Operator Mono SSm Lig", weight="DemiLight"},
-- /home/wez/.fonts/MaterialDesignIconsDesktop.ttf, FontDirs
"Material Design Icons Desktop",
-- /home/wez/.fonts/terminus-bold.otb, FontDirs
{family="Terminus", weight="Bold"},
-- /home/wez/.fonts/JetBrainsMono-Regular.ttf, FontDirs
"JetBrains Mono",
-- /home/wez/.fonts/NotoColorEmoji.ttf, FontDirs
"Noto Color Emoji",
-- /home/wez/.fonts/MaterialDesignIconsDesktop.ttf, FontConfig
"Material Design Icons Desktop",
-- /usr/share/fonts/terminus-fonts/ter-u32n.otb, FontConfig
"Terminus",
-- /home/wez/.fonts/JetBrainsMono-Regular.ttf, FontConfig
"JetBrains Mono",
-- /home/wez/.fonts/NotoColorEmoji.ttf, FontConfig
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Last Resort High-Efficiency",
})
```
we now compute the ratio of the cap height (the height of a capital
letter) vs. the em-square (which relates to our chosen point size) to
understand what proportion of the font point-size that a given font
occupies when rendered.
When rendering glyphs from secondary fonts we can use the cap height
ratios of both to scale the secondary font such that its effective
cap height matches that of the primary font.
In plainer-english: if you mix say bold, italic and regular text
style in the same line, and you have different font families for
those fonts, then they will now appear to be the same height where
previously they may have varied more noticeably.
For emoji and symbol fonts there may not be a cap-height metric
encoded in the font. We can however, improve our scaling: prior
to this commit we'd use the ratio of the cell metrics of the two
fonts to scale the icon/emoji glyph, but this could cause the glyph
to be slightly oversized as seen in https://github.com/wez/wezterm/issues/624
If we know the cap-height of the primary font then we can additionaly
apply that factor to scale the emoji to better fit the cell.
While looking at this, I noticed that the aspect ratio calculation
for when to apply to the allow_square_glyphs_to_overflow_width option
had width and height flipped :-(
See also: https://tonsky.me/blog/font-size/
refs: https://github.com/wez/wezterm/issues/624
This addresses the render artifacts aspect of https://github.com/wez/wezterm/issues/671
For whatever reason, some font(s) cannot be loaded on that system
and that results in the paint routine erroring out.
This commit avoids the error by substituting a blank glyph
instead of the glyph that failed to load.
refs: https://github.com/wez/wezterm/issues/671
This commit allows the x11 window implementation to detect changes
in the DPI that occur after a window is created.
These can occur when changing desktop resolution or when changing
the accessibility option for "Large Text" in gnome.
In order to avoid continually polling for the value on every resize,
we look for the `_GTK_EDGE_CONSTRAINTS` atom in our property change
notifications. This seems to be sent at least as often as the
dpi/scaling changes.
It's also worth noting that some dpi changes don't generate resize
events, so we can't just read the dpi value on every resize, because
we'd miss some of those changes.
Part of this commit changes the font scaling logic: previously
we'd keep a notion of "dpi scale" to apply. That dates from an
earlier time in wezterm where we didn't think that we knew an
actual dpi value.
The way that worked was that we'd compare our current guestimate
of the DPI against what we though the baseline OS dpi should be to
produce a scaling factor.
On X11 that dpi value is global and we'd effectively always produce
a revised scaling factor of 1 after we'd set up the initial window.
This commit changes that logic to just pass down the actual DPI value
to the font code. That DPI value already accounts for HiDPI scaling
so this is hopefully a NOP change for the other systems.
refs: https://github.com/wez/wezterm/issues/667
This was broken by b441be3ac9
For whatever reason, the breakage was only visible with the Iosveka
font on Windows. I couldn't reproduce it on my other systems, even
though the code technically applies to any system.
The breakage was: the metrics resulted in a difference of about 0.4
pixels being used for the descender with that particular font, resulting
in weird vertical alignment problems.
The offset needs to be computed against the ceil of the cell height,
which removes the fractional offset.
refs: https://github.com/wez/wezterm/issues/661
refs: https://github.com/wez/wezterm/issues/582
The repro scenario for this case was:
* open GNU nano
* hit enter twice
* type hello
* move the text cursor to the top line
* double click on hello
* hit enter
Prior to this commit, the selection would remain on the now-blank line
that previously held `hello`.
refs: #644
This has been a commonly requested feature in the past week,
and it's a reasonable one. The mux server inherited the
close-when-done behavior from when it used to be an alternate
front-end in the same executable as the gui, but it doesn't
need to be that way any more.
We also need to accomodate that case in the client: if the
newly attached domain doesn't result in any panes being imported,
we need to spawn a new command there in order to keep the client
alive. The pre-existing check for whether the mux was empty had
false positives because the local mux may still reference the
pane from the connection UI, which would finish closing out shortly
after we had decided not to spawn anything, and then the client
would close.
refs: https://github.com/wez/wezterm/issues/631
refs: https://github.com/wez/wezterm/issues/507
When line_height is specified, rather than applying the offset
to just the top of the cell, apply it in equal parts to the top
and the bottom so that the cell is vertically centered.
closes: https://github.com/wez/wezterm/issues/582
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.
Allow overriding ssh config options from the command line.
I don't want to replicate the many options that `ssh(1)` has;
this just exposes the `-oNAME=VALUE` syntax. The config names
are those from `man ssh_config`; `IdentityFile` rather than `-i`.
refs: #457
I wonder how long this has been broken... rather than spawning
into domain "local" it would try to spawn into "`local`" and fail
silently because the error message wasn't logged.
So let's log it, and let's fix it.
refs: https://github.com/wez/wezterm/issues/468
There are a few notable changes as a result:
* A number of `.ssh/config` options are now respected; host matching
and aliasing and identity file are the main things
* The authentication prompt is inline in the window, rather than
popping up a separate authentication window
Refs: https://github.com/wez/wezterm/issues/457
These now operate in terms of logical lines so they deal with
lines that have wrapped outside the viewport better than in
previous releases.
closes: https://github.com/wez/wezterm/issues/408
Rust 1.51 allows addressesing a long-standing TODO which was that we
shouldn't need to build a vendored copy of openssl on most sensible unix
systems.
We do require a vendored copy on macOS and Windows, but due to the way
that Cargo's feature resolver worked, it wasn't possible for this
requirement to be respected.
Rust 1.51 introduces `resolver="2"` which can deal with this feature
resolution!
https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
The upshot of this is that building wezterm on real unix systems that
are not macos will now link against the system libssl, resulting in both
a shorter compile time and less headaches arising from having a slightly
different openssl used by wezterm than the rest of the system.
cc: @jsgf
If shaping can't resolve some glyphs, queue the font locator
fallback resolution to another thread; meanwhile, a last resort
glyph is used.
That thread can trigger an invalidation once the fallback resolve
is complete, the window is invalidated and the last resort glyph
is replaced by the resolve glyph.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/508
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
There's something fishy with colorspaces and blending.
This commit removes the `window::Color` type and replaces
it and the confusing array of color types exposed by the
`palette` crate with a pair of much simpler types:
`LinearRgb` - a tuple of f32 linear color components
`SrgbaPixel` - the u32 sRGBA pixel representation
This doesn't change anything about rendering, it just
makes it a bit simpler and makes the SrgbaPixel -> LinearRgb
conversion happen slightly earlier which shaves off some
ad-hoc conversions.
Refs: https://github.com/wez/wezterm/issues/544
hoist the underlyine glyph retrieval out of the loop.
Precompute some color conversions (less effective until
the gamma branch is merged).
refs: https://github.com/wez/wezterm/issues/546
Switches from using a dynamic vertex buffer to an immutable
vertex buffer. This feels counter-intuitive to me; the purpose
of dynamic is to sustain frequent updates, but mapping the buffer
needs to synchronize with the GPU, and if we are rapidly invalidating
the window that can stall painting by tens of milliseconds.
Switching to an immutable buffer avoids the stall and makes
quad mapping more consistently < 10ms, but its still not
ideal.
refs: https://github.com/wez/wezterm/issues/546
* Make window invalidation more efficient by avoiding spawning a call
that spawns a call to invalidate the window. Just directly mark as
invalidated.
* Suppress default background erase
* hoist the bg_color calc for quads that don't have Cells outside of
its loop.
refs: https://github.com/wez/wezterm/issues/546
I'm not convinced that this is 100% good, but @fanzeyi reported
some latency when using tmux to mirror two sessions. The session
that was accepting interactive input responded quickly, but the
mirroring session was laggy.
This change connects the mux pane output event to window invalidation,
which should cause repaints to happen more often.
I couldn't reproduce the scenario above on my M1 mac, but that may
just be because M1 has dark magicks.
A casualty of b8dcfba9a4 was that
the decoded gif would get reset each time the texture filled up.
Take care to move that cached into the newly minted glyphcache.
Continuing along the same lines as the prior commit, the goal
of this commit is to remove the buffer transformation that was
part of uploading the texture to the GPU provided surface.
In order to do so:
* The sense of our local textures needs to change from bgra32 to rgba32.
bgra32 was a hangover from earlier versions of our window crate that
allowed direct-to-fb writes in software mode. We had to pick bgra32
for that for the broadest OS compatibility. I believe that that
constraint has been totally removed, although there is a chance that
this will flip the colors on macos.
* There was an additional linear-to-srgb conversion inlined in that
buffer transformation. I have no idea where that is needed because
the source data is carefully constructed as SRGB. I don't yet know
how to signal that, but for now I've moved that gamma correction
into the shader when we sample the texture.
With this change, timg playback now has vtparse as the hottest
region of code.
refs: #537
Two issues highlighted by profiling:
* Clearing the texture takes a non-trivial percentage of the profile.
The docs suggest that it is better to create a new texture than
to update large portions of a texture, so add some plumbing so
that we can do that in the first texture-full case.
* Next on the list is the code that translates from linear BGRA to
SRGBA. This is present for reasons that I believe are now legacy,
but for the moment: those two primitives now have faster and
easier implementations, so simplify to those.
This improves the timg video playback performance by ~10% for me.
refs: #537
I've been meaning to do this for a while; this commit moves
the escape sequence parsing into the thread that reads the
pty output which achieves two goals:
* Large escape sequences (eg: image protocols) that span multiple
4k buffers can be processed without ping-ponging between the
reader thread and the main gui thread
* That parsing can happen in the reader thread, keeping the gui
thread more responsive.
These changes free up the CPU during intensive operations such
as timg video playback.
This is a slight layering violation, in that this processing
really belongs to local pane (or any pane that embeds Terminal),
rather than generically at the Mux layer, but it's not any
worse a violation than `advance_bytes` already was.
refs: https://github.com/wez/wezterm/issues/537
The leftmost pixel was being set to at least 1 by the scale
function.
Fix that up by computing the x coordinate without calling
the scale function.
refs: https://github.com/wez/wezterm/issues/536
Using a boxed slice means that we hold exactly the memory required
for the file data, rather than the next-power-of-two, which can
be wasteful when a large number of images are being sent to
the terminal.
This is a API breaking change for termwiz, so bump its version.
refs: #534
While adding gif support I let this become unbounded.
This commit resolves that by categorizing images as either
single frame or animations.
Single frame images are decoded and held entirely in the texture
atlas, so occupy no additional space beyond the image file contents
and their sprite region in the texture atlas.
Animations are decoded into a set of frame bitmaps. There can be
up to 16 animations (each with their full set of frames) cached.
The individual frames may also exist within the texture atlas
if space permits.
refs: #534
https://i.giphy.com/media/3owvKqP4VSydZE4pvq/200w.gif cannot
be decoded as an animated gif due to this error: `No end code in lzw stream`
Ensure that we don't completely fail to process the render phase
as a result.
Previously, invalidation for animation was driven by the cursor
blink rate, which meant that animated gifs/pngs could not play
faster than 5fps (default blink interval is 200ms).
This commit calculates the next invalidation time based on the
closes next frame time of all animated cells in the viewport.
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
During a live resize, we could queue up a lot of `window-resized`
events, which is undesirable.
This commit introduces a simple but effective mechanism to manage this;
a given event can have at most one executing and one pending copy.
So if we get a burst of resize events (eg: during a live window resize)
that might have previously queued hundreds of discrete events, we now
get a more manageable situation with 1 executing and 1 queued.
With this change, a given event can only have 1 executing instance at a
time (with the exception that the open-uri event doesn't go through this
mechanism).
refs: https://github.com/wez/wezterm/issues/291
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
This is to support <https://github.com/wez/wezterm/issues/291>.
The window resized event happens asynchronously wrt. processing
a window resize, triggering at the end of the normal window
resize handling.
This commit introduces the notion of whether we are in full screen
mode or not in the underlying event callback, which is useful to
gate the desired feature, which is: when in full screen mode,
increase the padding for the window to center its content.
While poking around at this, I noticed that we weren't passing
the per-window config down to the code that computes the quad
locations for the window.
This commit also changes the font size increase/decrease behavior
so that in full screen mode it doesn't try to resize the window.
```lua
local wezterm = require 'wezterm';
wezterm.on("window-resized", function(window, pane)
local window_dims = window:get_dimensions();
local pane_dims = pane:get_dimensions();
local overrides = window:get_config_overrides() or {}
if not window_dims.is_full_screen then
if not overrides.window_padding then
-- not changing anything
return;
end
overrides.window_padding = nil;
else
-- Use only the middle 33%
local third = math.floor(window_dims.pixel_width / 3)
local new_padding = {
left = third,
right = third,
top = 0,
bottom = 0
};
if overrides.window_padding and new_padding.left == overrides.window_padding.left then
-- padding is same, avoid triggering further changes
return
end
overrides.window_padding = new_padding
end
window:set_config_overrides(overrides)
end);
return {
}
```
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
Manual test scenario:
```
wezterm -n --config adjust_window_size_when_changing_font_size=false --config 'exit_behavior="Hold"' start -- sh -c "echo '(...)'"
```
then CTRL +/- to change font size; the first cell of the `...` was
previously random garbage, now is more consistent.
refs: https://github.com/wez/wezterm/issues/478
mouse move events in the tab bar, and paint events, could cause
the title bar state to be recomputed.
Make sure that we don't trigger the status event to trigger for those.
refs: https://github.com/wez/wezterm/issues/500
I've only tested this on macos, but it should be cross platform,
with the caveat that Wayland doesn't let a window position itself,
so this won't work there.
We were using the value that was active when the window was created,
and never updating it.
This commit sweeps the interval check into the existing periodic
window maintenance routine.
refs: https://github.com/wez/wezterm/issues/500
The API isn't finalized; this is proof of concept for putting something
in the area to the right of the new tab button.
The info will be right aligned to the tab area.
```lua
local wezterm = require 'wezterm';
wezterm.on("update-right-status", function(window, pane)
-- demonstrates shelling out to get some external status.
-- wezterm will parse escape sequences output by the
-- child process and include them in the status area, too.
local success, date, stderr = wezterm.run_child_process({"date"})
-- Make it italic and underlined
window:set_right_status(wezterm.format({
{Attribute={Underline="Single"}},
{Attribute={Italic=true}},
{Text="Hello "..date},
}));
end)
return {
}
```
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
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
The Cascadia Code font has ligatures for `---` that consist of
a triple wide glyph followed by two zero-width glyphs. Rewrite
that into a single glyph that spans three cells and remove the
zero-width glyphs from the shaped info.
refs: https://github.com/wez/wezterm/issues/478
Connect the gui to the new shaping logic; this means that we
can now correctly render fg/bg color when the cursor moves
through the cells that comprise a ligature.
refs: https://github.com/wez/wezterm/issues/478
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
Refine the colorization logic to make it more of a blending operation.
Previously, we were relying on opengl to carry out blending between
layers on our behalf, but that wasn't perfect.
This commit is inspired by this post:
https://www.puredevsoftware.com/blog/2019/01/22/sub-pixel-gamma-correct-font-rendering/
and factors in the background color when computing the colorized
glyph.
This appears to reduce the dark fringes/edges that we were seeing
before, without noticeably changing the brightness of the result.
refs: #491
https://learnopengl.com/Advanced-Lighting/Gamma-Correction suggests
some good practices:
* Only enable SRGB output on the final draw call, so that all prior
stages can operate on linear values and avoid converting to/from
linear multiple times.
* The SRGBA textures automatically linearize when sampled, but:
* The RGB data must be SRGB (non-linear)
* The A channel is assumed to be linear!
This commit nudges us closer to that by:
* Converting the freetype coverage map from its linear value to
non-linear when rasterizing.
* Splitting the shader files into one per stage (background, lines,
glyphs) and only setting outputs_srgb for the glyph stage
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
This commit:
* Fixes up the alpha blending draw parameters as discussed in
https://github.com/glium/glium/issues/1844 and
https://github.com/PistonDevelopers/conrod/issues/1347
* Introduces `colorize` and `colorize_hsv` functions to the shader.
comments in the code explain those functions in detail.
As of this commit, `colorize_hsv` is what is used now. To my
eye on this mac, it produces blended glyphs with less noticeable
dark antialiasing fringes.
refs: #470
Is it *right*? Hard to say, but it looks better than
the behavior I see with master at the moment.
This is a partial revert of #413, but respins it to
try to get a better alpha value for glyphs.
refs: #413
refs: #470
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.
* 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 implements the deprecated NSUserNotification bits needed
to be able to handle clicking on a notification and open our choice
of URL.
Ideally we'd use the newer UserNotifications framework, but that
requires code signing.
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 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
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
Since we no longer have our fallback Software renderer (only mesa),
remove what has become an empty variant and hoist the GL state up
into RenderState, holding Option<RenderState> in the window.
It's been replaced with an opaque termwiz error type instead.
This is a bit of a more conservative approach than that in (refs: #407)
and has less of an impact on the surrounding code, which appeals to
me from a maintenance perspective.
refs: #406
refs: #407
```
printf "\x1b[4m\x1b[58;2;255;0;0mred underline\x1b[0m"
```
prints "red underline" in the foreground color, with an
underline that is bright red `rgb(255, 0, 0)`.
refs: https://github.com/wez/wezterm/issues/415
These aren't currently rendered, but the parser and model now support
recognizing expanded underline sequences:
```
CSI 24 m -> No underline
CSI 4 m -> Single underline
CSI 21 m -> Double underline
CSI 60 m -> Curly underline
CSI 61 m -> Dotted underline
CSI 62 m -> Dashed underline
CSI 58 ; 2 ; R ; G ; B m -> set underline color to specified true color RGB
CSI 58 ; 5 ; I m -> set underline color to palette index I (0-255)
CSI 59 -> restore underline color to default
```
The Curly, Dotted and Dashed CSI codes are a wezterm assignment in the
SGR space. This is by no means official; I just picked some numbers
that were not used based on the xterm ctrl sequences.
The color assignment codes 58 and 59 are prior art from Kitty.
refs: https://github.com/wez/wezterm/issues/415
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
This adopts a similar technique to that used to pass the wezterm
config to the term crate, but this time it is for passing it to
the window crate.
The use_ime option has been ported over to this new mechanism.
Hooks up toggling fullscreen mode on macos, with plumbing for
other systems.
I prefer not to use the "modern fullscreen" mode because I find
the transition animations in macOS are horrendously slow.
I'll make an option to allow selecting whether that is used or not
in a follow-on diff.
refs: https://github.com/wez/wezterm/issues/177
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.
This commit keeps the content from the last release check in a local
file and reads from that file on startup to set a two-line release
info banner in each new pane.
* Allow injecting some initial output to new panes
* Have the update checker set this new-pane-banner to a short
upsell to let the user know there is an update.
* Refactor toast notifications into their own crate
* Have the update checker call a new stub function that triggers
a toast notification with an URL... but it does nothing because
the rust ecosystem doesn't support this on macos yet and I'm
writing this code there
Tidies up the plumbing around pixel dimensions so that ImageData
can be rendered via the termwiztermtab bits.
I put this together to play with sticking the wezterm logo in
the close confirmation dialogs. I didn't end up using that though,
but have preserved the commented code for use in future hacking.
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`.
Make pane, tab, window close confirmations use the same core function.
Make that function accept mouse input so that closing the window with
a mouse click doesn't require switching to the keyboard to confirm
the close.
refs: #280
Revise logging so that we use info level for things that we want
to always log, and adjust the logger config to always log info
level messages.
That means shifting some warning level logs down lower to debug level so
that they aren't noisy.
closes: https://github.com/wez/wezterm/issues/388
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
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
164adb78e3 added blowing some
opengl related state during resize, however, on some systems
(BigSur with M1 silicon, perhaps also Intel?) and Windows 10
can generate a resize event before we've spun up opengl, so
we need to make this conditional.
refs: #359closes: #358
Previously, we'd enumerate the font dirs on every font resolve for
every bit of styled text.
This moves the new FontDatabase instances to be single instanced
in the FontConfiguration. The font-dirs will be scanned once
on a config reload, but the built-in in-memory fonts will only
every be enumerated once per FontConfiguration instance.
The recent addition of dynamic fallback resolution highlighted this
issue.
The test scenario is:
1. Output some glyphs that need dynamic fallback
2. ctrl-+ to change the font scaling
3. rasterization fails because of some bad cached state; the font_idx's
were invalidated by the scale change which reset the dynamically
discovered fallback fonts.
The resolution is to blow the glyph and shape caches when scaling
is changed.
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
Use the scaling factor between the font metrics for the base font
and those of the fallback font selected for a given glyph.
The scenario is this: the base font is typically the first one selected
from the font configuration. There may be multiple fallback fonts that
are different sizes; for instance, the Font Awesome font has glyphs that
are square in aspect and are thus about twice the width of a typical
textual monospace font. Similarly, Noto Color Emoji is another square
font but that has a single set of bitmap strikes at a fixed 128 px
square.
The shaper returns advance metrics in the scale of the containing font,
and the rasterizer will target the supplied size and dpi.
We need to scale these to match the base metrics.
Previously we used a crude heuristic to decide whether to scale,
and that happened to work for Noto Color Emoji but not for Font Awesome,
whose metrics were just inside the bounds of the heuristic.
This commit allows retrieving the metrics for a given font_idx so
that we can compute the correct scale factor without any heuristics,
and applies that to the rasterized glyph.
refs: https://github.com/wez/wezterm/issues/342
This is one of those massive time sinks that I almost regret...
As part of recent changes to dust-off the allsorts shaper, I noticed
that the harfbuzz shaper wasn't shaping as well as the allsorts one.
This commit:
* Adds emoji-test.txt, a text file you can `cat` to see how well
the emoji are shaped and rendered.
* Fixes (or at least, improves) the column width calculation for
combining sequences such as "deaf man" which was previously calculated
at 3 cells in width when it should have just been 2 cells wide, which
resulted in a weird "prismatic" effect during rendering where the
glyph would be rendered with an extra RHS portion of the glyph across
3 cells.
* Improved/simplified the clustering logic used to compute fallbacks.
Previously we could end up with some wonky/disjoint sequence of
undefined glyphs which wouldn't be successfully resolved from a
fallback font. We now make a better effort to consolidate runs of
undefined glyphs for fallback.
* For sequences such as "woman with veil: dark skin tone" that occupy a
single cell, the shaper may return 3 clusters with 3 glyphs in the
case that the font doesn't fully support this grapheme. At render
time we'd just take the last glyph from that sequence and render it,
resulting in eg: a female symbol in this particular case. It is
generally a bit more useful to show the first glyph in the sequence
(eg: person with veil) rather than the gender or skin tone, so the
renderer now checks for this kind of overlapping sequence and renders
only the first glyph from the sequence.
When subpixel or greyscale AA are in use, the glyph data includes
some lighter and darker shaded pixels. That's their purpose,
but if the fg and bg color are the same, the expectation is that
the glyph is invisible and we don't want "phantom" pixels around
the character.
This commit adjusts the shader to set the color to transparent
when the fg and bg are the same, and we are not rendering a color
emoji.
refs: #331
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.
9892b16d40 adjusted how the text
colors are produced; it resulted in some ugly dark edges, especially
on lighter backgrounds.
This commit routes that tint via an alpha compositing helper which
produces smoother edges.
refs: #320
This commit more cleanly separates the load from the render flags,
and fixes up the render call; at some point this got messed up such
that we'd never end up with freetype returning subpixel format data
(LCD) and instead we'd only ever get grayscale data.
With that fixed, it's apparent that the colorization of the glyph
data was wonky in the shader so this commit also cleans this up.
refs: #320
refs: #121
If you have a primary font whose height is a bit more than double the
width then a double-wide emoji would be scaled to a bit more than two
cells in width.
This commit adjust the glyph scaling to check both the x and y scaling
to ensure that they glyph fits within the appropriate number of cells.
This has the consequence of rendering eg: the heart emoji smaller than
in previous versions; the heart glyph is typically square but the
broadly used concept of width for the heart unicode character is a
single cell. Previously we'd incorrectly render this double wide.
I'm not sure of a way to do better than we are right now because
freetype doesn't provide much help for scaling this kind of bitmap
font AFAICS.
refs: #320
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.
Full error
```
error[E0277]: can't compare `&[u8]` with `std::vec::Vec<u8>`
--> wezterm-gui/src/gui/termwindow.rs:817:40
|
817 | if existing.data() == data {
| ^^ no implementation for `&[u8] == std::vec::Vec<u8>`
|
= help: the trait `std::cmp::PartialEq<std::vec::Vec<u8>>` is not implemented for `&[u8]`
error: aborting due to previous error
```
Needed to re-order a couple of things to match recent changes.
Also: don't hard fail if the ssh server rejects a setenv request,
just log the error instead.
A consequence of reducing the initial texture size is that for
larger starting font sizes it isn't big enough. We need to make
a couple of passes to determine the required size, so that's
what this commit does.
refs: #307
This commit moves a bunch of stuff around such that `wezterm` is now a
lighter-weight executable that knows how to spawn the gui, talk to
the mux or emit some escape sequences for imgcat.
The gui portion has been moved into `wezterm-gui`, a separate executable
that doesn't know about the CLI or imgcat functionality.
Importantly, `wezterm.exe` is no longer a window subsystem executable
on windows, which makes interactions such as `wezterm -h` feel more
natural when spawned from `cmd`, and should allow
`type foo.png | wezterm imgcat` to work as expected.
That said, I've only tested this on linux so far, and there's a good
chance that something mac or windows specific is broken by this
change and will need fixing up.
refs: #301
