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
```
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
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
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
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.
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
This commit adjusts the config loading code so that we can return
information about the paths the should be watched for a subsequent
reload even in the more common error cases.
refs: #1174
We need the mux window builder to notify in order for the ConnectionUI
to show up, but we wouldn't trigger the notify (which happens on drop)
until we'd awaited the connection ui completing password auth.
Force it to drop earlier to unblock.
refs: https://github.com/wez/wezterm/issues/2194
The issue here was that the from_dynamic impl derived for a struct
that was inlined in an enum didn't respect the the field properties
defined for the struct.
Refactor to reuse the same field_info helper used by the struct
code.
Update docs to clarify what the default value actually is.
refs: https://github.com/wez/wezterm/issues/2179
This commit adds more trace logging around selection
related events.
That tracing uncovered a situation, when multiple wezterm windows within
the same process were involved, where one window didn't receive a
selection-clear event notification.
Since Window::get_clipboard trusted our local understand of the
clipboard contents, it would return those until the selection was
changed in that window.
This commit changes that code to always ask the X server for the
selection. It makes pasting slightly slower, but should always produce
consistent results.
refs: https://github.com/wez/wezterm/issues/2110
This enables tentative support for https://sw.kovidgoyal.net/kitty/keyboard-protocol
It's only been lightly tested with the notcurses-input program and
eyeballed against a few random keypresses in kitty running
`printf "\x1b[=11u" ; od -c`
I tried with neovim, but it doesn't seem like the version available
in Fedora 36 supports this yet.
refs: https://github.com/wez/wezterm/issues/1141
The heart of the issue is that `sudo -i` sets the cwd to the homedir
of the root user, and that isn't accessible to the regular unprivileged
user, and cannot be set as the cwd for the newly spawned panes/tabs.
A secondary issue is that it is hard to see what the error is without
improved diagnostics.
So this improves the diagnostics, and then changes the existence
check that we were doing for local domain spawns to try to read the
directory instead.
refs: https://github.com/wez/wezterm/issues/2120
For fonts like Lucida Console on Windows which do not have a bold
variant, we were not synthesizing bold.
The reason was that the config-level "make bold" logic works by adding
200 to the weight which takes normal -> demibold, but the bold synthesis
logic is enabled only for bold and higher.
This commit changes the threshold for synthesis to demibold or higher.
refs: https://github.com/wez/wezterm/issues/2074
harfbuzz can return incomplete overlapping runs when it processes
text in unicode NFD. Add another check for the case where we've
accumulated the bytes in the range 0-12 and then harfbuzz returns
another range of 6-12. We coalesce the two together so that we can
pass the full unresolved sequence to the next fallback pass.
refs: https://github.com/wez/wezterm/issues/2032
This, along with the plumbing included here, allows specifying
the destination of the split (now you can specify top/left, whereas
previously it was limited to right/bottom), as well as the size
of the split, and also whether the split targets the node at the
top level of the tab rather than the active pane--that is referred
to as full-width in tmux terminology.
https://github.com/wez/wezterm/issues/578
Invalid option names, or values that evaluate as nil (such as the `foo`
above: that's treated as a global variable reference, but `foo` isn't a
defined global and evaluates as `nil`) will now cause the program
startup to error out with an actionable error message.
Previously, the invalid config name would generate a warning, and the
invalid value would silently have no effect as it has the same effect as
omitting the named value and leaving it as its default value.
I think these cases should both immediately error out and stop
further processing, so that's what we're doing.
This commit also adds support for adding:
```
#[dynamic(deprecated = "use newer option instead")]
pub some_config_value: bool,
```
but not options currently use this.
To do this, we split `Pattern` into the underlying pattern for the mux
layer (which is part of the codec), and another for the config layer,
so that we can specify this new mode.
At the gui layer, we translate the selection variant into the actual
selection text and map it to the mux Pattern enum.
When taking the selection text, we restrict it to just the first line.
refs: https://github.com/wez/wezterm/issues/1912
Turn on multi-line mode by default, and improve the localpane
search function to collapse runs of trailing whitespace into
just a newline.
That allows:
```
./target/debug/wezterm -n --config 'quick_select_patterns={"foo$"}'
```
to match the first line from this, but not the second:
```
printf "foo\nfoobar\n"
```
and this to match both:
```
./target/debug/wezterm -n --config 'quick_select_patterns={"^foo"}'
```
refs: https://github.com/wez/wezterm/issues/2008
The issue here was that we'd try to match this:
```
key_event RawKeyEvent { key: Char('t'), modifiers: ALT | LEFT_ALT, phys_code: Some(T), raw_code: 17, repeat_count: 1, key_is_down: true, handled: Handled(false) }
```
which has mods=`ALT|LEFT_ALT` against `ALT` and would fail.
We need to strip out the positional ALTs from the modifiers
in order to successfully match.
refs: https://github.com/wez/wezterm/issues/1958
This change causes key table activations to effectively layer
over prior key table activations.
This is necessary for the copy mode key assignment changes to
work.
refs: https://github.com/wez/wezterm/issues/993
I've bundled this into termwiz's UnicodeVersion type as that is
a similar concept that is already routed through to the appropriate
function.
refs: https://github.com/wez/wezterm/issues/1888
The launcher menu code to perform attaching has been generalized
into a key assignment action and reimplemented in terms of that
action.
A detach action has been added to disconnect and detach.
refs: https://github.com/wez/wezterm/issues/1874
This commit allows the currently active window to:
* Spawn a new tab in the active window (rather than spawning
a new window) to host the connection status
* Auto-close that connection UI tab (rather than the whole window)
when the window is no longer needed
* Pass the current window through to use as the primary window when
assigning remote window/tabs.
The net effect of this is that there are fewer transient windows,
and that it is easier to connect a set of domains to the active
workspace.
refs: https://github.com/wez/wezterm/issues/1874
We want to avoid normalizing control key presses; there were
two places where it was happening; one in our own code and
the other was in the xkeyboard mapping stuff itself.
refs: https://github.com/wez/wezterm/issues/1851
This persuades vim to set ttymouse=sgr by default.
We're carefully sitting below 279 which triggers
some queries for things that we don't respond to yet.
refs: https://github.com/wez/wezterm/issues/1825
Some versions of fontconfig classify some fonts as having charcell
spacing. We need to consider those as monospace as well.
refs: https://github.com/wez/wezterm/issues/1820
The keys section was way too big; this splits it up into more
manageable pieces, adds a nice flow chart to show how key events
are processed and adds an example of using the new key tables feature.
A bit of a PITA, this commit:
* Introduces a DeferredKeyCode type that defers resolving a concrete
keycode
* Adds key_map_preference config which can be Mapped or Physical
* Key map building resolves the keycode using key_map_preference
* Default key assignments have been re-phrased in order to produce
DeferredKeyCodes
* User-specified keys without `mapped:` or `phys:` prefixes will
resolve according to key_map_preference
refs: https://github.com/wez/wezterm/issues/1788
refs: https://github.com/wez/wezterm/issues/1784
Previously, we'd create a clipboard handler associated with a GUI window
and take care to pass that down to the underlying Pane whenever we
spawned a new pane.
For the mux server, instead of being associated with a GUI window, the
clipboard was a special RemoteClipboard that would send a PDU through
to the client that spawned the window.
The bug here was that when that client went away, the clipboard for
that window was broken.
If the mux server was the built-in mux in a gui process this could
leave a tab without working OSC 52 clipboard support.
This commit restructures things so that the Mux is responsible for
assigning a clipboard handler that rephrases the clipboard event
as a MuxNotification.
Both the GUI frontend and the mux server dispatcher already listen
for mux notifications and translate those events into appropriate
operations on the system clipboard or Pdus to send to the client(s).
refs: #1790
After killing the remote pane, we no longer trigger the renderable
poll stuff that would detect that the pane was dead.
Let's speculatively set it to dead so that we don't get stuck with
stray tabs/panes.
https://github.com/wez/wezterm/issues/1752
There were a a couple of issues:
* `ImageData::hash` would re-hash the image on every call, and this was
called for every cell that comprised an image on the mux server side
* `SerializedLine` needed to understand how to remove the `Arc<ImageData>`
image attachments so that we didn't serialize a complete copy of the
image per cell that comprised the image.
A new RPC was introduced to attempt to fetch `ImageData` given its
content hash and pane, row and cell index as a hint to locate it.
A client side LRU of content hash to `ImageData` is used to avoid
issuing repeat calls to that new RPC.
refs: #1237
Flesh out the get_os_parameters impl for macOS. When running on a
system that provides `NSScreen::safeAreaInsets`, use that to determine
the border required to avoid the "notch" on certain models of mac.
In the GUI layer: when the os parameters include a border, adjust
the render position to account for it.
This is a bit of a speculative change, as I don't have a mac with
a notch.
refs: https://github.com/wez/wezterm/issues/1737
This helper extracts the concrete set of hosts and their configurations
from the ssh config, and arranges to reload the wezterm config if they
are changed.
This is useful when constructing ssh domain configs.
refs: https://github.com/wez/wezterm/discussions/1731
The `open` crate blocks forever when spawning the browser via xdg-open,
which feels kinda "wrong" to me, but does offer a method that can stick
that in a background thread, so that's what we do here.
refs: #1721
