ubuntu's pip stuff is preventing me from doing a basic user
install and I've had trouble in the past with the svg related deps.
Let's just switch to using a docker based version of mkdocs.
This allows individual call sites to be able to force an immediate
resolution of the process information.
This should help to address https://github.com/wez/wezterm/issues/4811
wherein the problem seems to be that the cwd used for a new spawn
is taken from a stale read.
The workaround was to allow ctrl-c to behave as expected for users
of cyrillic layouts, but it was scoped too broadly, as it impacted
eg: pressing ctrl-grave; in a spanish layout that is expected to
expand to º
This commit adjusts the scope of the workaround to only activate
when the original expansion is itself cyrillic.
I doubt this is the last we'll hear of this, but let's see
how it goes!
refs: https://github.com/wez/wezterm/issues/4933
We were unconditionally checking against the cwd for relative paths,
which isn't conformant to posix's path search logic.
This commit revises the search to only do so if the requested executable
starts with either a `.` or `..` path component.
In addition, we now also allow for path components in $PATH to specify
cwd-relative paths.
refs: #4920
When the cwd was set to a directory that contained
an executable directory whose name matched the argv0
of the command to be spawned, we'd incorrectly consider
that to be a valid candidate.
When later trying to spawn this, we'll fail with an EACCESS,
and in the context of wezterm, rust's internal error handling
machinery for this error would fail to write to a descriptor
because our close_random_fds() function has closed that descriptor
during pre_exec. That in turn would cause rust to print a panic
message to the output stream of this semi-spawned process,
which would show briefly an error message with no useful context.
This commit resolves this issue by explicitly avoiding executable
directories in this case.
refs: https://github.com/wez/wezterm/issues/4920
I'm not sure if this is the right way to go about this, but it doesn't
immediately break some simple tests with non-us layouts for me, so
I'm willing to push it and see what people say.
refs: https://github.com/wez/wezterm/issues/4910
It used `::default()` rather than `::empty()` for the initial
set of bits, and since the two are no longer equivalent, it
prevented being able to assign `freetype_load_flags = 'DEFAULT'`.
refs: https://github.com/wez/wezterm/issues/4902
I meant to flip this back prior to cutting the most recent release,
and we've had a couple of issues already raised about WebGpu
and is transparency handling on Windows, and color/gamma.
I think I'll just leave this at OpenGL for a while, until WebGpu
catches up a bit better.
In https://github.com/wez/wezterm/issues/4877 it became clear that
the newer approach for finding fallback fonts is only better than
the old approach in some cases, so this commit adds a fallback
to the old approach if the new one didn't yield any usable results
for a given codepoint.
refs: #4099
