This reverts commit 2c95b98447.
More people were vocally and sometimes toxic about this change
than were in favor of it.
I'm just going to revert it and leave the original issue open.
refs: https://github.com/wez/wezterm/issues/2882
Otherwise it is just hidden forever. We can't use the proper declarative
interface, because we are faking quite some stuff for "-e", so instead
we mention it explicitly in the help output.
This is done for compatibility, as many tools assume that running a
command with "$TERMINAL -e $COMMAND" blocks until the command is
finished.
For example some tools delete a needed file after the command returns.
But since we always return immediately (in case --always-new-process is
not provided and if another wezterm instance is already running), this
would mean that the file is deleted before the command could do
anything.
Fixes#4523
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
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
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.
* Removed title update from main render loop
* Add to PaneFocused event
* term: only emit Alert::OutputSinceFocusLost for the first
seqno bump after losing focus, rather than on every bump.
That event indirectly causes the title to update
refs: https://github.com/wez/wezterm/issues/4788
This used to make things such that the copy button for `console`
blocks would only copy the input and not the output, but it
doesn't seem to have that effect any more, and now just prevents
selecting portions of the output.
That's a PITA because eg: the CLI --help pages use `console`
to show which options are available.
I think something has probably changed somewhere in upstream mkdocs
because this used to work as I mentioned above.
refs: https://github.com/squidfunk/mkdocs-material/issues/6697
test scenario is:
```
bash -c "sleep 5; for((i=0;i<30;i++)); do xdotool keydown --delay 0 Shift_L keydown --delay 0 9 keyup --delay 0 Shift_L keyup --delay 0 9; done"
```
That should cause a series of `(` characters to be emitted, but prior to
this commit is was usually mostly `9`'s.
What's changing here is:
* We copy the pertinent fields from the last xcb StateNotify event.
That ostensibly has the current modifier and layout state, but
because it comes from the X server, it doesn't factor in knowledge
from the IME.
* When processing an XCB key event, compute the current modifier
mask and override the XKB state with it.
* Now XKB will produce correct information about the key syms
* Restore the modifier state from the saved StateNotify information.
refs: https://github.com/wez/wezterm/pull/4151
refs: https://github.com/wez/wezterm/issues/4615
refs: https://github.com/fcitx/fcitx5/issues/893
refs: https://github.com/ibus/ibus/issues/2600
refs: https://github.com/wez/wezterm/issues/3840
