We were getting data like this back from harfbuzz:
shaped font_idx=0 "파인더에서 만든 폴더" as: [.notdef=0+448|.notdef=0+448|.notdef=6+448|.notde=6+448|.notdef=6+448|.notdef=15+448|.notdef=15+448|.notdef=21+448|.notdef=21+448|.notdef=27+448|.notdef=27+448|space=33+448|.notdef=34+448|.notdef=34+448|.notdef=34+448|.notdef=43+448|.notdef=43+448|.notdef=43+448|space=52+448|.notdef=53+448|.notdef=53+448|.notdef=53+448|.notdef=62+448|.notdef=62+448]
which had a series of discontiguous and repeated runs for the same
cluster/region, but due to a logic error, we weren't coalescing them
together and were passing somewhat nonsensical ranges to the
next font for shaping.
This commit "simply" ensures that we code the checks for codepoint==0
(the `.nodef` seen above) and the results are at least correct
for this particular case.
refs: https://github.com/wez/wezterm/issues/2482
ad9490ee8f unset SHELL from the
environment on startup which had the consequence of causing
`os.getenv("SHELL")` to return `nil` when used in the config file.
Rather than simply restoring SHELL env var, recognize that reading
the environment from a long lived process is prone to seeing
stable environment forever.
We already compensate for this in the pty crate's understanding
of the base environment, so this commit patches `os.getenv`
and replaces it with our own imlementation that uses that same
logic.
The base environment logic has been extended to set SHELL from
the passwd database to round things out.
refs: https://github.com/wez/wezterm/discussions/2481
There are caveats to determining this, but when we think
password entry is enabled, switch the cursor to the font-awesome
lock glyph instead of the normal cursor sprite.
fa_lock is used because it is monochrome and can thus be tinted
to the configured cursor color, and it respects blinking/easing.
refs: https://github.com/wez/wezterm/issues/2460
I've had a couple of people report issues like
https://github.com/wez/wezterm/issues/2378 recently, and we can avoid
this class of problem by unsetting SHELL at proces startup, so that's
what we do.
CTRL-SHIFT-U is a new default key assignment for this new modal.
It opens up a fuzzy searchable browser that defaults to showing
emoji/emoticons. The category can by cycled through the suggested
emoji categories using CTRL-r. Unlike the system emoji palette,
wezterm includes a category for nerdfont symbols, and another
that is a list of all unicode codepoint names, so you should be
able to browse for pretty much any codepoint you can think of.
The modal also allows fuzzy searching based on:
* The official unicode name
* The github shortcode
* codepoint value in hex
so if you know the codepoint value but not the name, you can
still find a way to input what you're looking for.
Pressing Enter will copy the selected item to the clipboard
send it to the active pane, and cancel the modal. You can therefore
repeat the insert by simply pasting.
I plan to add frecency to this in a later commit: that way the
frequently/recently used selections will show in a category of
their own and make it easier to re-input them.
refs: https://github.com/wez/wezterm/issues/2163
Inspecting the wezterm process with `lsof -p`, before and after closing
a pane with `CloseCurrentPane`, the same number of unix domain sockets
are open, which is bad.
This commit tries a bit harder to clean things up: if we got a process
exit condition we now remember that we had it, and, while processing
the IO for that channel, if we have no data for stdout or stderr
(respectively) and the channel exited, we close our end of the
socketpair to encourage EOF to be detected on the other end.
This is sufficient to restore the number of open files to the same
number wezterm had opened prior to opening that pane.
@chipsenkbeil: this might possibly be a factor in the issue you
reported, but I haven't had time to really dig into that yet!
refs: https://github.com/wez/wezterm/issues/2466
refs: https://github.com/wez/wezterm/issues/2456
It can have some surprising effects, so leave it at the basic logical
composition of cwd + relative rather than physical.
refs: https://github.com/wez/wezterm/issues/2449
It's not the first time that I've solved a problem by slowing things
down... in this situation, a couple of very inefficient TUI programs had
flickering outputs in wezterm because they were filling a buffer with a
bunch of spaces to erase a screen before sending the main body of their
updates in a subsequent buffer chunk. wezterm would render the
intervening partially blank frame and appear to flicker.
The resolution is to add a small delay (3ms by default) before sending
data to the terminal model. If the output is readable in that time
we'll accumulate it with the pending set of actions so that the
whole batch can be applied "more atomically".
Take care: `time cat bigfile` is sensitive to this, so we want to
keep the latency as small as possible, and we also want to avoid
accumulating actions and only flushing them at the end of the file.
We use the existing buffer size (~1MB) as a threshold: we bump
a count of the number of input bytes that resulted in the current
set of actions, and if that exceeds that buffer size we flush it.
refs: https://github.com/wez/wezterm/issues/2443
The prior mutually exclusive behavior kept surprising people so let's
just flip this around.
This is potentially a "breaking" change for folks, but I think it is
worth it.
`wezterm start -- /etc/profile` would crash on macOS because
`/etc/profile` isn't executable.
This commit checks for executable access as a prereq for both the
path search and the absolute path cases and generates a non-crashing
error:
```
$ wezterm start -- /etc/profile
17:24:03.574 ERROR wezterm_gui > Unable to spawn /etc/profile because it doesn't exist on the filesystem or is not executable (EACCES: Permission denied); terminating
```
I think I may have inadvertently changed whether the arch portion
was included in the filename for stable releases.
Allow for that in the regex.
Remove debian 9 which is no longer supported.
closes: https://github.com/wez/wezterm/issues/2382
Previously, we'd unconditionally enable dual source blending for the
text foreground layer when rendering. That meant that if the user had
configured the fg color to include an alpha value it would get "stamped
through" the draw all the way to the background, making that whole pixel
take on that alpha value rather than allowing it to blend through the
way you might expect.
In prior releases that didn't matter, but since we now allow configuring
the fg color with alpha, and allow using escape sequences to set the fg
for a span to something with alpha, there is now a much higher chance of
something looking weird.
Dual source blending is only really needed for subpixel-aa and that
isn't enabled by default.
This commit changes the behavior to use regular alpha blending if the
main config (rather than a per-font override) hasn't set the freetype
load/render target to one that enables subpixel-aa.
That means that alpha channel values work as expected for fg color
by default.
If you want to enable subpixel-aa you need to enable it globally
and be aware that it will cause weirdness when trying to use alpha
channels for the fg text color.
The docs now also indicate this behavior.
This limitation could be removed by making text rendering significantly
more complex and I don't fancy doing that at this time.
Consolidate the attributes together rather than having them in separate
versioned sections so that it is a bit more readable.
Make a note about how attributes select from existing fonts rather than
apply styling effects to fonts.
refs: https://github.com/wez/wezterm/issues/2348
They prevented using other types of mouse events!
We don't have a good way to specify that kind of alias, so for now,
take it out and replace the examples in the docs with the more verbose
equivalents.
refs: #2173
refs: #2296
Adjusts how mouse events are matched so that we can now indicate whether
mouse reporting and alt-screen should be considered as part of the event
trigger criteria.
refs: #2173
refs: #581
There was a race condition where we could leave the tab
active index pointing to the wrong pane.
That meant that the tab information computed by the gui
layer would see no panes marked as active, and thus would
end up with no active tab.
This commit fixes that by clamping the active index to
the number of panes.
refs: https://github.com/wez/wezterm/issues/2304
The recent work on the scrollback made it easier to constrain the
search region, so expose those parameters to the Pane::search
interface and to the mux protocol.
Use those new parameters to constrain quickselect search to
1000 rows above and below the current viewport by default, and
add a new parameter to QuickSelectArgs that allows overriding that
range.
A follow-up commit could make the search/copy overlay issue a series
of searches in chunks so that it avoids blocking the UI when
searching very large scrollback.
refs: https://github.com/wez/wezterm/pull/1317
Need to explicitly pop it in front of the tab text layer so that
the button is physically rendered on top of the tab title.
refs: https://github.com/wez/wezterm/issues/2269
Various color schemes have been duplicated as they have been added to
different scheme collections. They don't always have identical names
(eg: some remove spaces) and sometimes they have very different names
(eg: _bash vs. nightfox, or Miu vs. Blazer).
We already detected duplicates from different collections but previously
we would omit those dupes.
This commit allows us to track those duplicates by recording their
aliases.
When we write out our data, we only include "interesting" alias names;
those where the name isn't trivially identical.
Some scheme collections (eg: iterm2 color schemes) have duplicates
(eg: zenbones and zenbones_light are identical) and we have previously
shipped with both of those names, so we special case to emit dupes
for which we have prior version information in order to avoid
breaking backwards compatibility for our users.
In the doc generation we can generate links to the aliases if we
included them, but also note about the other names and how we don't
include them. That is so that someone searching the docs for say
"_bash" can discover that it is actually a duplicate of "nightfox" and
use nightfox instead.
This allows the hook to choose how to handle eg: `wezterm start -- top`.
Previously, if you had implemented this event you would essentially lose
the ability to specify a command that you wanted to launch.
refs: https://github.com/wez/wezterm/issues/284
This simplifies the "change scheme based on dark mode" example
a lot. This was previously impossible to do because we didn't
have a lua module associated with the gui until recently, so
the only way to reference a gui-related object was via an
event callback.
refs: https://github.com/wez/wezterm/issues/2258
Record the version in which we first saw a color scheme.
For schemes from iterm2-color-schemes, we just assume that
we've had them forever as it isn't easy to reverse engineer
that metadata.
Everything else is tagged as 'nightly builds only' and I'll update
that to match the version number in the next release.
Newly discovered items will be added with 'nightly builds only'
from this point onwards.
Originally I had names like `base 16:foo` but wanted `foo` to
sort with `f` rather than `b`, so this prefix extraction
handled that.
I later changed the names to be `foo (base 16)` so we don't
need this.
This moves the `X::Erosion` scheme to sort under `x` where it
feels more natural.
Ensure that scheme_data.rs has a deterministic sort order that
matches the json data.
Adjust importer to read directly from the source .itermcolors
files in the upstream repo. Extract some author information
from the comments in those files.
All data is now fetched (and cached!) via relatively minimal
http requests rather than requiring a git repo locally.
Also search for .yml files in base16 repos; found another
couple of schemes this way.
The toml files under assets/colors are no longer read by
anything in the repo. I plan to remove them, but since the
docs reference them as examples, I will first ensure that
there are docs and tooling that explains how to write and
share your own scheme files.
Attach the mux events to the frontend workspace reconciliation function
so that the window is updated to match the new workspace.
Ensure that we correctly clear out any overlay panes as part of the
switch: we need to remove them from the mux so that the mux will
correctly identify that the mux is empty when the main panes from
the workspace are closed. The problem case was that the debug overlay
state was forgotten by the gui when activating the new workspace, but
we didn't tell the mux to kill it off, so subsequently CTRL-D'ing
the windows closed the windows but left the wezterm process running with
no head.
refs: #2248
We don't really know which of the on-screen matches the user was
looking at when they selected the text, but assume that the one
nearest the bottom of the viewport is the one they want to select,
rather than the one closest to the top.
refs: https://github.com/wez/wezterm/issues/2250
Moved the gradient function into the color module, but kept an alias
under the old name.
Gradients now return color objects.
Converting colors to string now uses rgba format when alpha is not 100%.
Otherwise we can block the gui waiting for eg: a freshly opened firefox to
terminate.
See also comment worrying about this in
75066cb522.
That fear was realized but now resolved!
refs: https://github.com/wez/wezterm/issues/2245
wezterm.color.parse() returns a color object that can be assigned in the
wezterm color config, and that can be used to adjust hue, saturation and
lightness, as well as calculate harmonizing colors (complements, triads,
squares) from the RGB/HSL color wheel.
This commit expands the toml file definition to include
metadata for the origin url, author and name.
A new sync utility fills out that metadata when it pulls from the iterm2
color schemes repo.
The utility also pulls down the scheme data json maintained by
the Gogh project: https://gogh-co.github.io/Gogh/ and converts
it to wezterm's format.
About 50% of Gogh overlaps with iterm2; we take the iterm2 versions
of those schemes by default because the iterm2 data has more info
about things like cursor and selection colors.
The sync utility is responsible for compiling the de-duplicated
set of scheme data into a form that is used by wezterm and its
docs.
I've wanted to avoid checking in all the screenshot pics as the png
files change every time I run the generation script, and it bloats
the repo over time.
This commit changes the doc generation step to use the asciinema
web player with the equivalent contents.
Really, it's only a smallish step to go from this to just emitting
the html directly in the doc pages, but I think I might use
the player for some examples in the future.
I think this is still a fine step for now in any case.
While comparing this with the existing screenshots, I noticed the
the Alabaster screen shot png has the wrong color for its rightmost
column: there's an issue in wezterm in parsing the dynamic color
escapes that causes it to pick up the wrong color.
Loading the scheme by name has the correct color and matches
how it is shown as of this commit.
Not sure why this only really showed up with Wayland, because the
issue was that the computed tab bar height ended up being 1 or 2
pixels shorter than the area we had allotted.
This commit resolves it by forcing the height to match, and
then aligning the content to the bottom of that region to avoid
having an undesirable line under the tab.
refs: #1256
