This makes the search feel more responsive.
We search from bottom to top so that we show the more recent results
first, but for the sake of efficiency when accumulating result chunks
we need to reverse the order of the results vec from how it was
previously.
Each result chunk is loosely ordered from top to bottom, so we sort
it and reverse it: results[0] is the bottom-most result.
New rows are accumulated on the end of the result array; this is
not only more efficient, but it preverses the match result number
ordering.
The next/prior functions need to be swapped to account for this change
in result order.
refs: https://github.com/wez/wezterm/issues/1209
It was set to the first non-tab bar pixel y coordinate rather than
the line y pixel coordinate.
Move the calculation up!
refs: https://github.com/wez/wezterm/issues/2483
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
I don't think these are really necessary any more; the implementation
cannot go out of bounds, so the worst that can happen is that we
don't return any changes.
refs: https://github.com/wez/wezterm/issues/2222
This commit is a result of debugging a problem with a particular font
where a VS2 variation of a glyph produced incorrect shaping.
Further investigation showed that this was specific to using freetype
font functions and that switching to opentype functions produces the
correct shaping information in that case.
Further-further investigation showed that this difference in behavior
was really due to the font file being out of spec and freetype returning
unexpected data as a result.
This commit allows switching to using harfbuzz's own opentype font+face
(rather than freetype) and/or switching the freetype-based font to using
opentype font functions. These two options don't yield equivalent
results in the wezterm integration: a couple of our shaping tests
fail due to the x-advances not being the same. Those can be drastically
different in some cases (eg: I seem to get 0 for certain bitmap strikes,
and for Roboto the value is off by a factor of about 1.5).
This is incomplete and not something I want to turn on by default at
the moment, but I don't want to lose this work, hence this commit.
refs: https://github.com/wez/wezterm/issues/2475
refs: https://github.com/harfbuzz/harfbuzz/issues/3806
We've been using hb with freetype faces. This gives us the option
of using harfbuzz's own opentype based face and function set.
It doesn't change any behavior: this is just newly available code.
refs: https://github.com/wez/wezterm/issues/2475
More recent versions of harfbuzz conveniently generate harfbuzz.cc
which has the full list of source files, so point our build to
that instead of chasing the evolving list of files: much easier!
Fixup some of the predefined symbols, and include opentype functions
in bindings.h so that we can pick those up in the bindgen output.
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
The idea here is that different kinds of panes may want to expose
additional metadata to lua scripts. It would be a bit weird to add
a Pane method for each of those and plumb it all the way through
the various APIs, so just allowing a pane impl to return a dynamic
value (likely an Object) allows a bunch of flexibility.
This commit exposes the clientpane is_tardy boolean and the time
since the last data was recevied (since_last_response_ms) from
the mux client pane implementation: these are used to show the
tardiness indicator in the client pane.
Exposing this data enables the user to add that info to their
status bar if they wish.
The default behavior for charselect is to show the recent category
if you have previously used it, otherwise, show the default emotion
category.
refs: https://github.com/wez/wezterm/issues/2163
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
