This commit expands quick select mode so that you can trigger it
with distinct sets of patterns (eg: urls on one key assignment,
hashes on a different key assignment), different alphabets,
and lastly, the option to perform a different action from
the default copy action.
You can pair this with `action_callback` to run lua code to
do something with the selected text.
This commit also adds `wezterm.open_with`, a helper function
for opening documents/URLs.
refs: #846
refs: #1362
The label dedup code has panicked on me a couple of times.
I managed to capture the line number, so this commit aims to
capture some state to try to understand what's going on,
and importantly, to avoid the actual panic part.
refs: #1271
permits iTerm2 images to be drawn anywhere on screen without
scrolling the cursor, including the bottom row.
Also included is a check in fcwrap.rs to_range_set(), without which
was causing a panic at runtime due to subtraction from unsigned
leading to overflow.
This helps us correctly set the size of the image cell
for the case where we have a partial cell at the right/bottom
edge of an image being mapped across cells.
refs: #1270
Move away from the imprecise simple pow version and over to a
version that properly respects the linear and non-linear portions
of the curve.
refs: #1025
On Windows, both EGL and MESA render modes were too dark.
After a bit of hunting around what I found made EGL and MESA
consistent with my default nVidia GPL rendering was:
* Tell glium that our shader outputs srgb
* Add explicit gamma conversion from linear to srgb in the shader
AFAICT, that shouldn't be required, but it seems as though something
deep in glium really wants to apply some kind of gamma conversion,
and it seems to select the wrong kind unless we set things explicitly
to SRGB.
There are some people complaining about this in
https://github.com/glium/glium/issues/1615.
I actually tried to move entirely aware from the glium srgbtexture2d
type in the hope of having explicit control over the gamma, but the
issue is in what happens to the outputs rather than the inputs.
It appears to me as though the text now looks slightly less
intense, so I think this may be what we need for the gamma issue
in https://github.com/wez/wezterm/issues/544 and potentially
also https://github.com/wez/wezterm/issues/1025
refs: https://github.com/wez/wezterm/issues/1373
Adds some plumbing to allow the GUI to implement a download handler
and connect that up for iterm2 image/file transfers that have their
inline property set to false.
Previously we'd just log an error.
Now we will by default download the file to the user's download
directory.
This behavior can be turned off via the new `allow_download_protocols`
configuration setting.
File transfers can be initiated on a remote host via the
https://iterm2.com/utilities/it2dl script.
When the download completes, a toast notification is shown that will
open the file when clicked.
refs: https://github.com/wez/wezterm/discussions/1450
Remove special case for blocks where we switched it out for a blank
sprite and instead varied the cell background.
We now always render a matching cursor sprite as a separate layer
over the top of the text background color, but below the text
foreground layer.
This is preparing for https://github.com/wez/wezterm/issues/1432
Make bar/line cursors use the text foreground color when reverse
video cursors are enabled, per @VKondakoff:
https://github.com/wez/wezterm/issues/1076#issuecomment-978214136
Finally getting around to fixing this usability wart: this commit
changes the behavior of Window closing so that you can close a window
containing multiplexer panes without prompting and without killing
off those panes.
This is achieved through some plumbing:
* The mux can now advise Domains about an impending window closure,
giving them the opportunity to "do things" in readiness.
* The mux client domain informs the container ClientPane instances
to ignore the next Pane::kill call, which would otherwise inform
the mux server to kill the remote pane
* Pane:can_close_without_prompting now requires a CloseReason.
* ClientPane's can_close_without_prompting impl allows Window closing
without prompting on the assumption that the ignore-next-kill hack
above is working
refs: #848
refs: #917
refs: #1224
The mux client just returns a dummy reader, and some overlays
have panicking stubs: just allow for them to return None
instead of potentially spawning a useless thread.
Previously, we would only look at the `check_for_updates` config
on startup.
This commit adjusts the update checker logic so that we always
start it, and that we respect config reloads.
Only show the update window and/or generate a toast notification
is the current wezterm-gui process is the eldest of the set of
running wezterm-guis.
This avoids spamming the user with update information.
refs: https://github.com/wez/wezterm/issues/1402
This code was partially replicating the initial window setup
where we didn't necessarily know the dpi, but in the context
where this is run, we do know the dpi for the window, so
let's consistently use that number throughout.
refs: #1039
The intent is to workaround what appears to be an i3 bug.
Not totally sure this is a good change, but let's try it!
Might also help with an issue on macos.
refs: #1140
refs: #1310
This moves away from using special block glyphs for the lines and
just draws lines directly.
In addition, since these lines are no longer constrained to available
glyphs or glyph boundaries, we can now render lines that cross when
there are a mix of horizontal and vertical splits, which looks a
bit nicer.
refs: #1256
Assuming that the window config reloaded hook doesn't actually change
anything, this will avoid a cycle where we keep triggering the hook
over and over.
This is a fairly far-reaching commit. The idea is:
* Introduce a unicode_version config that specifies the default level
of unicode conformance for each newly created Terminal (each Pane)
* The unicode_version is passed down to the `grapheme_column_width`
function which interprets the width based on the version
* `Cell` records the width so that later calculations don't need to
know the unicode version
In a subsequent diff, I will introduce an escape sequence that allows
setting/pushing/popping the unicode version so that it can be overridden
via eg: a shell alias prior to launching an application that uses a
different version of unicode from the default.
This approach allows output from multiple applications with differing
understanding of unicode to coexist on the same screen a little more
sanely.
Note that the default `unicode_version` is set to 9, which means that
emoji presentation selectors are now by-default ignored. This was
selected to better match the level of support in widely deployed
applications.
I expect to raise that default version in the future.
Also worth noting: there are a number of callers of
`unicode_column_width` in things like overlays and lua helper functions
that pass `None` for the unicode version: these will assume the latest
known-to-wezterm/termwiz version of unicode to be desired. If those
overlays do things with emoji presentation selectors, then there may be
some alignment artifacts. That can be tackled in a follow up commit.
refs: #1231
refs: #997
It appears as though Menlo is the only font on macos to contain the
heavy ballot cross symbol, which is commonly used on macos (eg: in
`brew` output).
Our fallback list, despite starting with Menlo, didn't include menlo
itself in the candidates.
Furthermore, `ls-fonts` wouldn never see the result of the system
fallback resolution because it didn't know to try again, and was
using the list of handles from before the fallback.
This commit resolves all of these concerns.
refs: #849
Since we may have two different sizes/namespaces of fonts between
the title font and the main terminal font, we need to be a bit more
careful to pass down distinguishing font information when caching
glyphs.
In addition, I noticed that the advance for custom block glyphs
(eg: powerline!) weren't right in the tab bar. To resolve this,
when shaping, we skip using the glyph from the font and synthesize
a placeholder with the appropriate advance.
We were truncating the right-status text because we were passing
the padded number of cols for the tab bar, but since the tab bar
now exists outside the padding, that value was too small.
This commit introduces the `Dimension` type which allows specifying
a value in a variety of units; pixels, points, cells, percent.
`Dimension` needs contextual information to be evaluated as pixel
values, which makes resolving the value from the config slightly
more of a chore.
However, this type allows more flexible configurations that scale
with the font size and display dpi.
refs: #1124, #291, #195
The previous commit was partially OK, but the main cause of
emoji being wonky was this bit of macos specific code that I
added ages ago.
Remove that hack and the portion of the code from the previous
commit that was working to undo it.
This should make the baselines consistent across all platforms.
refs: #1203
Avoid accidentally scaling the tab bar when using IncreaseFontSize.
Use a "better" default title font based on the platform.
Avoid a gap between bottom of tab button and dividing line at
certain font sizes.
When split horizontally, selecting multiple lines at the top of the left
pane could paint a horizontal selection line all the way across the rest
of the terminal to the right hand edge.
Removes the dependency on knowing where the pane top/left position
is so that the line render routine could be used in more places.
Adjusts the tab bar and scroll bar positioning so that the tab bar
ignores window padding and is always flush with the top/bottom window
edge (full width as well), and that the scroll bar top/bottom respects
the tab bar position and height.
More of a "fix"; we use some heuristics based on the bearing
and glyph width to figure out if a sequence looks like a funky
ligature that moves left to render the glyph.
This may be prone to false positives, but the consequences are low:
when we think a glyph is part of a ligature, then rather than using
the cursor_fg color (which is typically black, or close to invisible),
we retain the normal text fg color.
This way the portion of the glyph outside of the cursor retains its
foreground color, and just the cell containing the cursor may have
a slightly funky fg color in the case where the heuristic was bad.
closes: #478
`use_fancy_tab_bar` switches to an alternate rendering of the tab
bar that uses the window_frame config to get a proportional
title font to use to render tabs, as well as rendering a few
additional elements to space out and make the tabs feel more
like tabs.
Computing the number of tabs doesn't respect the alternate font
at this time.
Formatted tab item foreground and background colors are also
not respected at this time.
refs: #1180
We now compute the cap-height from the rasterized glyph data.
Moved the scaling action of use_cap_height_to_scale_fallback_fonts from
glyphcache into the font resolver: when enabled, and we have data
about the baseline font and the font being resolved, then the resolving
font will be scaled such that the cap-height of both fonts has the same
pixel size.
The effect of this is that `I` glyphs from both fonts should appear to
have the same height.
Added a row of `I`'s in differing styles at the bottom of styles.txt
to make this easier to visualize.
refs: #1189
This is to handle situations such as some versions of the Terminus
bitmap font, where the individual bitmap strike sizes are broken
out across multiple individual files.
Font matching now passes down the nominal pixel height based on
the current DPI and font scale factor, and will use that to select
the font file that has the closest pixel size.
Previously, it would be potentially undefined which of the Terminus
font files would be selected.
refs: https://github.com/wez/wezterm/issues/1189
This commit adjusts the the window event routing/queuing so that
a queued event can capture a pane_id other than the focused pane.
Since we only allow one queued instance of a given named event in a
window, a consequence of this is that multiple bell events coming
from different panes at the same time may race and the loser's
event will be dropped. We log a warning in that case.
refs: #3
This commit introduces a mechanism for specifying resize increments
for a window, and then arranges for the termwindow to set those
to match the current font cell metrics.
This should help to avoid cases where there is excess padding pixels
resulting from the window being slightly larger than computed number
of cells and the font metrics.
Fast-clicking users generally expect to be able to rapidly do regular selections
or otherwise cancel double/triple/quad clicks, so significant mouse movement should end the streak.
Allowing tiny pixel movements to account for touchpads is necessary.
Fortunately, the position here is already in character grid cells, which provides enough margin for this.
Other code editors like gedit also seem to do this based on the character grid.
It appears as though kakoune hides the terminal cursor and renders
its own version of the cursor.
The hidden state was being picked up by the copymode overlay,
making it awkward to use.
This commit forces the cursor to be visible (and a block) when
copy mode is active.
closes: #1113
I think this is a hangover from the older logic to figure out
the initial sizing, and I suspect that it is what is causing
refs: 1074
So this is a speculative change to see if it helps!
This splits rendering into 3 passes:
* background pass for z-index < 0. This is for solid background colors,
background images, and image attachments with z-index < 0.
Rendered with regular alpha blending.
* glyph pass: for glyphs at z-index==0. This is rendered with dual
source blending enabled to facilitate subpixel aa appearance.
* top layer pass for z-index >= 0 graphics. This is rendered with
regular alpha blending.
This avoids weird effects, like images with alpha shining through
the back of the window when the window itself isn't transparent.
refs: #544
transparent images weren't always blending correctly, and were
instead shining through.
This might also have affected cursors.
It may also be a factor in a couple of recent reports of excessive
boldness which looked like funky over-alpha multiplication.
Let's see what people say about this.
This makes the comparison in https://github.com/wez/wezterm/issues/544
work for me on mac, linux (x11, wayland) and also on Windows but
only using WGL.
It looks like we can use the proper colorspace on all targets
except for ANGLE EGL. For whatever reason, the combination of
glium and ANGLE EGL on windows over-gamma corrects.
AFAICT, the framebuffer and perhaps the surfaces it creates
don't indicate srgb support, and whatever combination of status
they return tickles glium's srgb stuff the wrong way.
I think the "solution" is just to directly use WGL by default.
EGL was on by default because it tended to be more survivable
when graphics card drivers were updated, but the last couple
of times I updated mine it still killed wezterm anyway.
refs: #544
Add a more general dragging thingy and use that to know when we
are dragging splits or the scroll thumb.
Fixup scrollbar math, which didn't account for whether the tabbar
was shown and which might cause the scroll thumb to jump around
on first drag (resolves#568)
The idea here is to make it a bit easier to do hit detection for UI
elements; today we've been duplicating position math between the render
and the mouse movement handlers, with both pieces of code knowing the
location of the UI element.
UIItem allows the render phase to record the position, which allows
the mouse phase to be a more independent lookup against the registered
elements.
This makes it easier to add more UI elements in the future.
If a cell contained a ligature, the math used to track where the
next quad was going to be placed could lose consistency with
the cluster/shaping information and result in offset glyphs.
This was most noticeable to me in tab titles in the tab bar;
my shell dotfiles append `-- something` to the title when a
command is launched, and the `--` is a ligature in my font.
I think I've also seen this mess up positioning in the notcurses
demo as well.
The solution is to take the cluster initial cell index rather
than trying to reverse engineer it from incomplete info.
This commit annotates fonts with a boolean that indicates whether
we think it contains glyphs with emoji presentation, and then
passes the cluster.presentation field down to the shaper.
If the presentation doesn't match the current font in the fallback,
then it will be skipped until we exhaust its options.
`wezterm ls-fonts` also shows whether we think a font has emoji
presentation.
refs: #997
This replaces the slightly gnarly subpixel enabled blending in the
shader with Dual Source Blending, which is a technique where the
fragment shader can specify both the primary color (RGBA) as well
as an additional per-channel mask that can be used to alpha blend
with the destination.
This enables artifact-free alpha blending when used together
with a transparent window background.
refs: https://github.com/wez/wezterm/issues/932
Terminal now maintains a sequence number that increments
for each Action that is applied to it.
Changes to lines are tagged with the current sequence number.
This makes it a bit easier to reason about when an individual
line has changed relative to some point in "time"; the consumer
of the terminal can sample the current sequence number and then
can later determine which lines have changed since that point
in time.
refs: https://github.com/wez/wezterm/issues/867
Use the newer logical line method in pane rather than going
via the hyperlink function, so that we can better reason
about physical vs. logical line breaks, and get the results
very slightly faster too.
refs: #874
We were previously only remembering the most recently pressed
button, but that's a lossy thing to do.
This commit remembers the button presses so that we can correctly
report all press/release events.
refs: #973
I think this is the heart of the initial size issues:
during creation, if the dpi or size is different, we generate
a resize event, but because it is dispatched before we've
assigned self.window, we weren't able to resize the window
to fit.
This commit passes the Window object down to the resize
handler so that it can do that; the diff is conceptually
small but there is corresponding fanout around ensuring
that the Window is passed down through all the resize
related codepaths that need it.
refs: #1002
refs: #695
It seems like this is making things worse on X11/Wayland.
Let's try simply skipping it--that seems fine on X11/Wayland,
but needs to be verified on macOS and Windows.
refs: #1002
refs: #695
The intent is to avoid weirdness with Wayland where we need to wait for
a configure event before we try to set the window size programmatically.
refs: #1002
WindowState is a bitfield that can represent maximized, full screen
and hidden window states.
WindowState is passed along with resize events, improving on the
prior basic is_full_screen boolean by representing the other states.
Notably, WindowState::MAXIMIZED is used to represent a state where
the window's size is constrained by some window environment function;
it could be due to the window being maximized in either or both the
vertical or horizontal directions, or by the window being in a tiled
state on any edge.
When the window is MAXIMIZED, wezterm will behave as though
`adjust_window_size_when_changing_font_size = false` because it knows
that it cannot adjust the window size in that state.
This potentially helps with #695, depending on whether the window
manager propagates this state information to wezterm. Gnome/mutter
does a good job at this with both X11 and Wayland, but I couldn't get
sway to report these states and I don't know of any other tiling wm
that I can easily install and use on fedora, so there's a question
mark around that.
This commit changes the full surface fill to be fully transparent,
and adds a separate quad to fill with the configured window background
color.
The thesis is that this should avoid the apparent weird rgb/srgb
mismatch that seems to occur with the window background on Intel macs
(those have a different OpenGL implementation than M1 based macs which
don't appear to have this issue).
refs: https://github.com/wez/wezterm/issues/1000
refs: https://github.com/wez/wezterm/issues/653
I noticed that on macos, the initial terminal size didn't
match the 80x24 default; it was a few columns short.
I think I broke this with recent changes in window
event dispatching.
This commit passes the terminal size down to apply_dimensions
just after we've set up the GL context to preserve the
terminal size.
Possibly related to https://github.com/wez/wezterm/issues/1002
This should help to avoid artifacts in the case where glyphs
render outside their nominal terminal cell (happens when the
shaper tweaks positioning, and/or when ligatures are involved).
Previously we'd render the layers in z-index order for cell N
before the layers in z-index order for cell N+1.
If N had an image that overlayed the text (nominally z-index 0.5!)
and the glyph in N+1 (z-index 0) was slightly to the left of its
border, then it could layer incorrectly over the cell to the left.
The underlying types in termwiz support 10-bit color, but in our
conversion to the data we pass to the vertex, we were forcing it
into 8-bit and then converting to float.
Simplify this by skipping the intermediate 8-bit representation
and just go directly to float.
I'm not sure if this is needed now that we have a single draw call, but
based on the history and the nuance of different gl/driver/os quirks it
feels like a good idea to keep this option in the back pocket.
Since we can now mutate individual frames, we need to avoid
falsely caching across a change; switch from using (image_id, frame_idx)
to frame_hash.
refs: #986
Adds a use_image feature to termwiz that enables an optional
dep on the image crate. This in turn allows decoding of animation
formats (gif, apng) from file data, but more crucially, allows
modeling animation frames at the termwiz layer, which is a pre-req
for enabling kitty img protocol animation support.
refs: #986
Rather than leaving the frame un-rendered, this commit arranges
to make one last pass but with all image quad assignments skipped.
This should at least make a reasonable effort at displaying text
on the screen.
refs: https://github.com/wez/wezterm/issues/879
I noticed when running the notcurses demo that we're spending a
decent amount of time decoding png data whenever we need to
re-do the texture atlas.
Let's avoid that by allowing for ImageData at the termwiz layer
to represent both the image file format and decoded rgba8 data.
This commit is a bit muddy and also includes some stuff to try
to delete placements from the model. It's not perfect by any
means--more expensive than I want, and there's something funky
that causes a large number of images to build up during some
phases of the demo.
refs: #986
OpenGL will silently let us allocate a texture larger than the GPU can
bind to a sampler, reporting the error status out of band and leaving
the display in a perma-broken state.
This commit deliberately checks against the max texture size and raises
an error in that case.
The recovery story isn't perfect, but at least the texture remains
usable, so the user can clear the screen and still be able to see glyphs
afterwards.
refs: https://github.com/wez/wezterm/issues/879
Taking further advantage of dynamic quad allocation, we can now
remove the multiple render passes in favor of allocating the quads
and painting them from back to front.
In turn, this means that we can reduce the amount of data that we
store in the vertex, which simplifies the shaders a bit, at the
expense of making the render code in rust a bit more complex.
However, we can take advantage of stretching runs of cells with
background colors in to a single quad.
refs: #986
This was added in 365a68dfb8 to free the
orca from its cage. With the recent dynamic quad allocation changes, we
don't need a distinct 4th pass any more and can simply layer a separate
quad on top of the glyph quad.
refs: #986
This removes the pre-allocated (at resize) number of quads
and replaces it with a dynamic mechanism that tracks how many
quads are needed for a frame and then will re-allocate and
re-render when there weren't enough.
We start with 1024 quads and try to allocate in multiples
of 1024 quads.
refs: #986
This commit removes the `Quads` struct which maintained pre-defined quad
indices for each of the cells, the background image and scrollbar thumb.
In its place, we now "dynamically" hand out quads to meet the needs of
what is being rendered. There are some efficiency gains here with
things like the selection (which can now be a single stretched quad,
rather than `n` quads in width).
This isn't a fully dynamic allocation scheme, as we still allocate the
current worst case number of quads when resizing.
A following commit will adjust that so that we allocate a ballpark and
then employ a mechanism similar to OutOfTextureSpace to grow and retry a
render pass when we need more quads.
Futhermore, this dynamic approach may allow reducing the amount of stuff
we have in the Vertex and "simply" render some quads before others so
that we don't have to have so many draw() passes to build up the
complete scene.
refs: #986
This teaches termwiz to recognize and encode the APC
sequences used by the kitty image protocol.
This doesn't include support for animations, just the
transmit, placement and delete requests.
refs: #986
In the case where the cells vec is shorter than the line width,
we need to ensure that we render the inverse video background
color if that mode is in effect.
refs: #133
Also fixes an issue where only the first frame schedule would
take effect! Surprised this didn't bubble up as a bug with
animated gifs already.
refs: #133
This commit introduces a 4th draw pass for rendering sixel and
iterm images that are attached to cells.
Previously, a cell could container either text or an image from
the perspective of the renderer. If it had an image then the glyph
bitmap would be ignored in favor of the image.
However, that causes sixel behavior to diverge from other terminals
(https://github.com/wez/wezterm/issues/942) so we need to be render
both of these.
The simplest way to achieve this is to add a distinct set of texture
coordinates for the attached image and then add a draw pass to alpha
blend it over the glyph content.
The sixel/iterm image processing stage is also adjusted to preserve
the prior cell information and "simply" attach the image info to
the cell. Previously, the cell would be replaced with a blank cell
with the image attached.
The result of this is that the notcurses-demo intro section can
now render the orca "enveloped in the soft glow of glyphs" rather
than caged in a black box.
Note that there are some cases where the render turns blocky but
I suspect that that is due to some other misunderstanding between
wezterm and notcurses and that we'll root cause it as a follow up.
Looking at #900; the unconditional directory change on startup
is "bad" because it only happens on Windows.
This commit removes it and instead puts the logic into the pty
layer to match the unix behavior.
The behavior is:
* If the command specifies the cwd, use that.
* Otherwise, use the home directory
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.
It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.
refs: https://github.com/wez/wezterm/issues/894
refs: https://github.com/wez/wezterm/issues/806
This allows window-level config overrides to apply
to panes contained within the window.
For instance, this allows setting a window-level
color scheme.
While looking at https://github.com/wez/wezterm/issues/945 I noticed
that mouse moves were being considered to be drag events even though
no mouse buttons were held down.
I added this originally thinking that it would make it easier to resolve
https://github.com/wez/wezterm/issues/695 and to integrate wgpu support,
but it's the cause of https://github.com/wez/wezterm/issues/922 so let's
take it out and more directly connect the window events to those in the
terminal.
This commit likely breaks mac and windows; pushing it so that I can
check it out and verify on those systems.
0.8 doesn't seem to build with rusttls, but I don't think
we need that any more: we've been using vendored openssl on windows
and mac for some time.
closes: #924
refs: https://github.com/jayjamesjay/http_req/issues/48
Previously, if the config file had errors, ls-fonts would silently
continue with the default config, which was confusing.
Make a point of checking and reporting config file errors.
You can run `cargo build --release --no-default-features` to build
without wayland support.
This is useful for systems that do not have wayland (eg: the `slint`
distro).
This section of the code wasn't looking up the custom glyphs
and would always use the font. We can make rendering a little
more efficient if we skip the font resolution for this case,
and the code is much simpler if we just use our own box drawing
glyphs, so that's what we're doing here.
refs: #584
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
