I can't think of a good reason for this being here. I think I
may have been lazy about resolving the lifetime annotations
and just stuck in an extra buffer while building the original
version of this logic, and then forgot about it.
This commit resolves the lifetime annotations and directly
references the passed in buffer.
refs: https://github.com/wez/wezterm/issues/2626
I spent a few hours in heap profilers. What I found was:
* Inefficient use of heap when building up runs of
`Action::Print(char)`.
-> Solve by adding `Action::PrintString(String)`
and accumulating utf8 bytes rather than u32 codepoints.
* Inefficient use of heap when building Quad buffers: the default
exponential growth of `Vec` tended to waste 40%-75% of the allocated
capacity, and since we could keep ~1024 of these in cache, there's
a lot of potential for waste.
-> Solve by bounding the growth to 64 at a time. This has similar
characteristics to exponential growth at the default 80x24 terminal
size. May need to add a config option for this step size for users
with very large terminals.
* Lazy eviction from the LFU caches. The underlying cache advisor is
somewhat probabilistic and has a minimum cache size of 256, making
it difficult to maintain low heap utilization.
-> Solve by replacing it with a very simple LFU algorithm. It doesn't
seem to hurt much at the default terminal size with the default
cache sizes. If we make the cache sizes smaller, its overhead is
reduced.
Some further experimentation is needed to adjust defaults, but this
should help reduce heap usage.
refs: https://github.com/wez/wezterm/issues/2626
It can be helpful for debugging purposes.
The socket can be discovered by setting:
WEZTERM_LOG=wezterm_mux_server_impl::local=trace,info
to get it to log a line like:
```
setting up /Users/wez/.local/share/wezterm/gui-sock-38183
```
Then it can be helpful to do:
```
WEZTERM_UNIX_SOCKET=/Users/wez/.local/share/wezterm/gui-sock-38183 wezterm cli list
```
to see what is in the gui's mux model.
refs: https://github.com/wez/wezterm/issues/2616
I noticed from https://github.com/void-linux/void-packages/pull/36903
that 32-bit systems were failing to pass the test suite.
Running `cargo test --target i686-unknown-linux-gnu -- --nocapture
teeny_string` showed that we were faulting in the teenystring code
and digging a bit deeper showed that it was because our assumptions
about the high bits were wrong for 32-bit systems.
Fix this by making TeenyString based around a u64 rather than usize
so that we guarantee its size on all current systems.
When using `key_map_preference="Mapped"`, `ctrl-shift-1` is actually
`ctrl-shift-!` in a US layout.
This commit adds the us-layout mapping for shifted number keys to
allow that to work, but it is worth calling out that this will only
be meaningful in layouts that have the same US mapping for the number
keys.
refs: https://github.com/wez/wezterm/issues/2623
This sequence forms a grapheme with cell_width=2, but harfbuzz returns
it as two distinct clusters, causing our prior logic to shape them
independently from different fonts, but our logic for assessing width
would resolve them both to the same cell and double-count their width,
leading to issues with the rendered result.
This commit revises our clustering logic to add a pass that compares
the harfbuzz cluster positions with the cell-based positions from
the presentation_width that may have been provided. We use the starting
cell positions from that to order and de-dup so that clusters aren't
split in the wrong place.
refs: https://github.com/wez/wezterm/issues/2572
We weren't including the invisible space cells into the model
as part of building up the logical line, resulting in the logical
line being shorter than it should have been.
That resulted in some of the components of the double wide cells
not being rendered in the correct place.
refs: https://github.com/wez/wezterm/issues/2571
refs: https://github.com/wez/wezterm/issues/2568
We weren't matching the domain id when resolving the remote->local pane
mapping, which meant that having 2 or more mux client domains active
would lead to associating eg: remote pane id 1 with whichever local
pane was associated with any remote pane id 1 *first*.
This commit requires that both the domain id and the remote pane id
match.
refs: https://github.com/wez/wezterm/issues/2616
When closing the all mux tabs in a window, the remote will close
the window. If the local has a mixture of local and remote tabs
then subsequent attempts to spawn a tab in that window would
fail due to reusing the stale remote window id.
This commit purges the local/remote mappings that are (probably)
dead when the remote indicates that a pane has been removed.
The mapping should be re-established as needed later on.
refs: https://github.com/wez/wezterm/issues/2614
As explained in the comments, the Nautilus 4.0 API just passes files without the window object (which was unused anyway). This small fix keeps compatibility with the 3.0 API and checks the number of arguments.
Would be really nice if you could make this count towards hacktoberfest as well!
