1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-25 14:22:37 +03:00
Commit Graph

308 Commits

Author SHA1 Message Date
Wez Furlong
c042005ee0
mux: try harder to use default_workspace from config
There were a couple of cases where we didn't look at the config
when deciding on the workspace name.

refs: https://github.com/wez/wezterm/issues/2981
2023-01-19 07:47:27 -07:00
Wez Furlong
d34297cd2c
update base64, work around another batch of breaking API changes
closes: https://github.com/wez/wezterm/pull/2931
2023-01-08 18:49:45 -07:00
Wez Furlong
aefbb6b4a0
deps: update ntapi to 0.4
Avoids:

```
warning: the following packages contain code that will be rejected by a future version of Rust: ntapi v0.3.7
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 36`
```
2022-12-30 08:37:53 -07:00
Wez Furlong
4b3660d166
macos: allow running when there are no windows
Most of this commit is refactoring the spawn logic so that we
can reuse most of it to handle spawn requests when there is
no GUI window.
2022-12-21 00:31:58 -07:00
Wez Furlong
19b01261cb
mux: avoid deadlock in mux server
Ensure that we don't need a lock to examine the tab_id
2022-12-19 22:06:59 -07:00
Wez Furlong
e020a9f6cd
fix windows build 2022-12-19 15:21:13 -07:00
Wez Furlong
02eb0b4294
mux: rename Mux::get() -> try_get(), add "infallible" Mux::get()
This allows removing a bunch of unwrap/expect calls.

However, my primary motive was to replace the cases where we used
Mux::get() == None to indicate that we were not on the main thread.

A separate API has been added to test for that explicitly rather than
implicitly.
2022-12-19 11:55:35 -07:00
Wez Furlong
478cc59be3
mux: Mux is now Send+Sync 2022-12-19 11:54:02 -07:00
Wez Furlong
ee2aac0902
mux: require that Domain be Send + Sync 2022-12-19 11:52:38 -07:00
Wez Furlong
920ee853b3
mux: switch RefCell to RwLock internally
This is a step towards making it Send+Sync.

I'm a little cagey about this in the long term, as there are some mux
operations that may technically require multiple fields to be locked for
their duration: allowing free-threaded access may introduce some subtle
(or not so subtle!) interleaving conditions where the overall mux state
is not yet consistent.

I'm thinking of prune_dead_windows kicking in while the mux is in the
middle of being manipulated.

I did try an initial pass of just moving everything under one lock, but
there is already quite a lot of mixed read/write access to different
aspects of the mux.

We'll see what bubbles up later!
2022-12-19 11:52:38 -07:00
Wez Furlong
696148941c
Rc<Tab> -> Arc<Tab> 2022-12-19 11:52:38 -07:00
Wez Furlong
b58d026542
mux: make Tab Send+Sync 2022-12-19 11:52:38 -07:00
Wez Furlong
9e67ad7861
mux: reduce context switching when parsing output
Now that we use Arc<Pane> we can directly pass the pane to the
background thread that we're using to parse the terminal output, cutting
out some context switching and reducing the latency between output and
rendering that output.
2022-12-19 11:52:37 -07:00
Wez Furlong
aa3d722e1f
mux: add notify_from_any_thread helper 2022-12-19 11:52:37 -07:00
Wez Furlong
6e06b9af02
mux: Pane is now required to be Send+Sync. Use Arc<dyn Pane> 2022-12-19 11:52:33 -07:00
Wez Furlong
91ea1095c9
deps: update base64
closes: https://github.com/wez/wezterm/pull/2855
2022-12-12 09:15:09 -07:00
Wez Furlong
8479be7465
Basic useless wgpu based rendering foundation 2022-11-18 10:03:49 -07:00
Wez Furlong
43f2265ef1 deps: textwrap -> 0.16
closes: https://github.com/wez/wezterm/pull/2664
2022-10-23 20:50:47 -07:00
Wez Furlong
b1faba9d8a deps: upgrade finl_unicode to 1.2 2022-10-23 12:07:00 -07:00
Wez Furlong
35ce2fe74d trim heap usage
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
2022-10-22 17:10:36 -07:00
Wez Furlong
61752504dd use iter_panes_ignoring zoom in more places in the mux
`iter_panes` returns the renderable set of panes, but most functions
in the mux want to operate on the full set of panes.

Notably, when closing a tab, we were not killing panes other than
the zoomed pane, which caused wezterm to linger in the background.

refs: https://github.com/wez/wezterm/issues/2548
2022-09-23 16:44:03 -07:00
Wez Furlong
8e7a2cce79 overlays: pass down window config and apply overrides
refs: https://github.com/wez/wezterm/issues/2544
2022-09-23 05:00:31 -07:00
Wez Furlong
7f65c2242b copy-mode: vim style jump to character motion
refs: https://github.com/wez/wezterm/issues/2528
2022-09-20 19:52:20 -07:00
Wez Furlong
85db555b37 deps: update finl_unicode 2022-09-16 07:47:33 -07:00
Wez Furlong
96c4e7e9b9 Switch to finl_unicode for grapheme clustering
According to its benchmarks, it's almost 2x faster than
unicode_segmentation.  It doesn't appear to make a visible
difference to `time cat bigfile`, but I'll take anything
that gives more headroom for such little effort of switching.
2022-09-10 07:15:49 -07:00
Wez Furlong
5cae889ca4 remove test for deleted method 2022-09-07 07:55:08 -07:00
Wez Furlong
026b9e3577 fix hyperlink underlines
There were two problems:

* We weren't correctly invalidating when the hover state changed
  (a recent regression caused by recent caching changes)
* We'd underline every link with the same destination on hover,
  not just the one under the mouse (longstanding wart)

Recent changes allow the application layer to reference the underlying
Lines directly, so we can restore the original and expected
only-highlight-under-the-mouse by switching to those newer APIs.

Adjust the cache values so that we know to also verify the current
highlight and invalidate.

I was a little surprised to see that this also works with mux client
panes: I was expecting to need to do some follow up on those because
they return copies of Line rather than references to them. That happens
to work because the mux client updates the hyperlinks at the time where
it inserts into its cache. The effect of that is that lines in mux
client panes won't update to new hyperlink rules if they were received
prior to a change in the config.

refs: https://github.com/wez/wezterm/issues/2496
2022-09-07 07:51:28 -07:00
Wez Furlong
7d4b8249d7 add switch_to_last_active_tab_when_closing_tab config option
refs: https://github.com/wez/wezterm/issues/2487
2022-09-05 10:28:02 -07:00
Wez Furlong
5f7738899b fix build on windows 2022-09-02 09:53:20 -07:00
Wez Furlong
1b9ea2de3f change text cursor to fa_lock when entering passwords
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
2022-09-02 09:00:28 -07:00
Wez Furlong
14c613a064 add Pane::get_metadata
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.
2022-09-01 21:27:49 -07:00
Wez Furlong
c0a841eecb pty: set SHELL to the shell we selected
refs: #2469
2022-09-01 05:37:51 -07:00
Wez Furlong
0974c631e2 mux: gracefully handle socketpair failure
Avoids panicking when the process runs out of resources, but doesn't
address the underlying resource issue.

refs: https://github.com/wez/wezterm/issues/2466
2022-08-30 07:11:30 -07:00
Wez Furlong
3fab3aaf21 mux: refactor emit_output_for_pane and use it for exit_behavior
The logic in the exit_behavior case was a bit smarter than that
in emit_output_for_pane, so adopt the former in the latter, then
use the latter for the former!
2022-08-30 07:10:32 -07:00
Wez Furlong
28b4a0d16b Add some comments about new Pane methods and helpers 2022-08-27 08:07:26 -07:00
Wez Furlong
cb9fe1a676 flesh out some todos with new pane trait methods
Tidy some things up to avoid some dead code and redundant impls.
Make it easier to select whether you want to implement the new
methods in terms of the old, or the old methods in terms of
the new in a given pane impl.
2022-08-27 07:58:17 -07:00
Wez Furlong
b7b1e4020a revise Pane line related funcs
Adds Pane::for_each_logical_line_in_stable_range_mut and
Pane::with_lines_mut which allow iterating mutably over lines.

The idea is that this will allow the renderer to directly cache
data in the Line via its appdata without having to build cumbersome
external caching logic and managing cache keys.

This commit just swaps the implementation around for localpane
and sanity checks that the renderer functions.

Various overlays and the mux client don't properly implement these
yet and current warn at compile time and panic at runtime.

To follow is the logic to cache the data and make sure that it
works the way that I think before converting the other Pane
implementations.
2022-08-26 08:05:06 -07:00
Wez Furlong
5e993c581a termwiz: remove reverse video attribute from Line
It didn't really belong there; it was added as a bit of a hack
to propagate screen reverse video mode.

Move that to the RenderableDims struct and remove the related
bits from Line
2022-08-24 22:43:47 -07:00
Wez Furlong
f59e1d5fff mux: remove stale portion of comment from Pane::get_lines
we haven't had dirty bits in a long while
2022-08-24 20:19:15 -07:00
Wez Furlong
e05b3581b8 optimize Pane::get_lines_with_hyperlinks_applied for empty rules case
It's ~30x cheaper to just get the underlying lines when there
are no hyperlink rules defined (3us vs 112us)
2022-08-23 17:20:46 -07:00
Wez Furlong
00ddfbf9b8 perf: cache quads by line
Introduces a heap-based quad allocator that we cache on a per-line
basis, so if a line is unchanged we simply need to copy the previously
computed set of quads for it into the gpu quad buffer.

The results are encouraging wrt. constructing those quads; the
`quad_buffer_apply` is the cost of the copy operation, compare with
`render_screen_line_opengl` which is the cost of computing the quads;
it's 300x better at the p50 and >100x better at p95 for a full-screen
updating program:

full 2880x1800 screen top:

```
STAT                                             p50      p75      p95
Key(quad_buffer_apply)                           2.26µs   5.22µs   9.60µs
Key(render_screen_line_opengl)                   610.30µs 905.22µs 1.33ms
Key(gui.paint.opengl)                            35.39ms  37.75ms  45.88ms
```

However, the extra buffering does increase the latency of
`gui.paint.opengl` (the overall cost of painting a frame); contrast the
above with the latency in the same scenario with the current `main`
(rather than this branch):

```
Key(gui.paint.opengl)                            19.14ms  21.10ms  28.18ms
```

Note that for an idle screen this latency is ~1.5ms but that is also true
of `main`.

While the overall latency in the histogram isn't a slam dunk,
running `time cat bigfile` is ~10% faster on my mac.

I'm sure there's something that can be shaved off to get a more
convincing win.
2022-08-23 06:37:12 -07:00
Wez Furlong
7caaf136e4 compensate for flickery TUI programs by going slower(!)
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
2022-08-21 14:40:06 -07:00
Wez Furlong
de89d650a3 cargo update 2022-08-21 08:51:16 -07:00
Wez Furlong
cb75b642f7 Fixup ActivatePaneDirection to respect edge intersection
d2892c6 switched to using recency only, but neglected to verify that
the edges of the candidate panes were actually touching, leading to
some weird results.

This commit uses recency only when the edges intersect, otherwise,
scores 0 for the candidate.

refs: #2374
2022-08-20 07:20:07 -07:00
Wez Furlong
517cdc9c1b fixup build for pty api change 2022-08-12 08:45:02 -07:00
Wez Furlong
e6421d1b72 pty: try_clone_writer -> take_writer
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.

The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.

I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.

refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
2022-08-12 07:56:46 -07:00
Wez Furlong
d2892c6ff0 ActivatePaneDirection uses recency to resolve ambiguous moves
refs: https://github.com/wez/wezterm/issues/2374
2022-08-08 21:16:01 -07:00
Wez Furlong
ef532fc7e5 mux: adjust window size after attach
Since the initial attach is async, we'd create the window at the
default/initial size and then never reconcile the size of the remote
tabs once they'd attached.

This commit introduces an event that allows the gui window to do that.

The action that it takes is to take the max width and height between
its current size and the size of a newly added tab and resizes to
that new size, if it changed.

refs: https://github.com/wez/wezterm/issues/2133
refs: https://github.com/wez/wezterm/issues/2351
2022-08-05 07:53:44 -07:00
Wez Furlong
9c75292450 flatpak: use /.flatpak-info file to test if we are in flatpak sandbox 2022-08-03 07:04:31 -07:00
Wez Furlong
404d742c14 Teach wezterm how to spawn programs when running in flatpak
This commit allows wezterm to spawn programs into the host rather
than in the container environment.

It feels weird that it is so trivial to "break out" of the container
sandbox, but I'm not complaining.

There are some unfortunate consequences:

* there is no `wezterm` installed on the host, so no ability to `wezterm
  cli` to control it from other apps
* The unix domain socket is scoped inside the sandbox, so there's "no
  way" for `wezterm cli` to reach inside anyway.

But: with this, it is at least usable to start a flatpak and open a
shell.

refs: https://github.com/wez/wezterm/issues/2229
2022-08-03 07:04:31 -07:00