Matching against the current dir when it includes a host and a
path seems like a handy way to automate selecting appropriate
theme/color/profile settings, so I'd like to make sure that
we have the full URL content available for that.
Refs: https://github.com/wez/wezterm/issues/115
Refs: https://github.com/wez/wezterm/issues/117
This mostly works, but has a cache invalidation issue wrt.
passing invalidated rows from the server to the client...
sometimes.
However, scrollback is cached on demand and selection works.
We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
This is another option to help with the portable wezterm on a flash
drive use case.
When the font system is set to FontKitAndFreeType, the set of
directories specified by the `font_dirs` configuration option will
be scanned for fonts and used as a source for fonts.
In addition, any relative paths in the the `font_dirs` list will
be expanded relative to the configuration file path.
That allows deploying the following set of files to the root of
a flash drive:
* wezterm.exe
* wezterm.toml
* fonts/myfont.ttf
and with this config snippet:
```
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
```
wezterm will now consider myfont.ttf when loading fonts.
Refs: https://github.com/wez/wezterm/issues/73
This commit adds two new font system variants that are currently
implemented only on Windows:
* FontKit - uses fontkit both for font discovery and rasterizing
* FontKitAndFreeType - uses fontkit for font discovery but freetype
for rasterizing
To a certain extent, FontKitAndFreeType obsoletes FontLoaderAndFreeType
and I'll be looking at removing it once I can test the build on macOS.
The FontKit impl has bad metrics and also crashes during shaping
on Windows, so it's not ready to be used by default.
Even with setting this, I'm 0 for 4 different systems in having the
notifications actually stay on the screen until dismissed.
This was successful at displaying a notification on the pixelbook
desktop though, so that's 1/3 linux systems that have had success.
This was honestly a PITA because of its complexity. The `clipboard`
crate (now dropped as a dep) didn't support wayland, so I looked at
the `smithay-clipboard` crate, which caused all of my input to become
laggy just by enabling it--even without actually copying or pasting!
Both of those crates try to hide a number of details of working with
the clipboard from the embedding application, but that works against
our window crate implementation, so I decided to integrate it into
the window crate using Futures so that the underlying IPC timing and
potential for the peer to flake out are not completely hidden.
This first commit removes the SystemClipboard type from wezterm
and instead bridges the window crate clipboard to the term crate
Clipboard concept.
The clipboard must be associated with a window in order to function
at all on Wayland, to we place the get/set operations in WindowOps.
This commit effectively breaks the keyboard on the other window
environments; will fix those up in follow on commits.
It will pass the message text to the shell without proper quoting
which results in it running all sorts of garbage depending on
the message you're trying to display.
Very scary!
refs: https://github.com/jdm/tinyfiledialogs-rs/issues/19
We need to chunk the data that we read from the child otherwise
we may potentially try to admit more data in a single action
than the ratelimiter will ever allow (eg: if we read 4k of data
and the limit is 100 bytes per second, we can never send that
4k of data in a single write).
Our handling of that situation was not good: we'd panic and kill
the background thread that was reading the data, but the rest
of the app was still running.
This commit upgrades to the most recent rate limiter crate
and performs explicit chunking of the output so that we
behave more sanely.
Refs: https://github.com/wez/wezterm/issues/65
This is a little ghetto feeling because we're just stealing the top
line from the terminal model, rather than rendering anything
particularly native, but it is relatively quick and easy to do,
and helps improve the feel when using wezterm on a chromebook
inside crostini; in that environment, the system doesn't render
any text in the window titlebars (WTF!?) so it is desirable
to show something to help navigate the UI.
The tab bar is off by default for now; we'll definitely want to
add options to configure at least the colors, and perhaps add
a keybinding to toggle it at runtime.
```
enable_tab_bar = true
```
While adding support for the tab bar, I found a couple of little
bugs relating to computing the number of rows and columns; one
was during resize where we'd use the prior size instead of
the current size. Another was during tab spawning where we'd use
a slightly different calculation to determine the size and end
up raising an error about being confused about the screen size.
This is still a bit rough because the terminal parser doesn't
understand the pixel sizes, so it relies on the hard coded
cell dimensions being accurate.
This uses the same plumbing as the software frontend, but tries
to enable opengl.
None of the opengl rendering is plumbed through here yet, so this
is currently functionally identical to the software renderer.
Tested only on windows with a USB serial connector to my NUC running
linux.
This allows opening up wezterm on a serial port connection.
Serial is closer to a tty than a pty, so it is a bit different
to configure and use.
This commit allows running:
```
wezterm serial COM3
```
to open a window that connects to the specified COM port.
You can change the baud rate with:
```
wezterm serial --baud 9600 COM3
```
There are more options that could be set, but I'm a bit lazy and
have only exposed the baud rate to the wezterm cli so far.
In the early days we relied upon the bounded length of a sync channel
to put back pressure on the output from a child command. We're no
longer using that kind of channel, so here's a more deliberate and
measurable rate limiting implementation.
The `ratelimit_output_bytes_per_second` configuration setting defaults
to 2MB/s and constrains the amount of text we send to the escape
sequence parser.
This value was selected based on it being a combination of responsive
to ctrl-c while outputing a lot of data and still generating sleeps
to remain within the constraints.
This does mean that terminal benchmarks that test how quickly you
can dump text to the terminal will hit this artifical upper limit
and are thus not going to be a true measure of performance.
It's taking a while for https://github.com/jwilm/vte/pull/20 to get
merged, so point to my branch directly while I build out some
tunneled mux protocol escape sequences.
I'll need to fork vte on crates.io if vte doesn't merge the PR
before the next termwiz crate bump.
This removes some awkwardness in the impl by allowing casting
to a concrete implementation. This is a pattern I want to use
more widely and this diff proves the concept.
When enabled, the windows version will use winpty rather than conpty.
This potentially allows running on older windows versions but has
a few caveats:
* Requires winpty.dll and winpty-agent.exe be in the PATH
* The initial screen / cursor position looks funky for me with the
latest release of winpty, but that is from a couple of years ago
* Mouse reporting doesn't work, perhaps for the same reasons that
it isn't working in conpty.
I want to make this into a runtime selectable feature before tidying
up the installation aspects; we need that plumbing anyway to be
able to select between local and remote mux'd tabs.
This is primarily for macos where the default freetype
installation is unable to render color emoji, but should also
help make things more consistent across the various platforms.
It's a little bit awkward on linux because the font-loader crate
pulls in the now-conflicting servo-font* crates. I've disabled
font-loader on linux systems; it's just calling fontconfig under
the covers anyway.
Reduces the size of the full screen serialized size from 40k -> 13k.
Note that the `zlo` crate (which doesn't appear to have a repo
on github any longer; sources are only found in the crates.io
documentation source view), employes zigzag encoding of all integers
and floating point values and takes the size down to just under 10k.
A todo is to follow up on that and see if we could adopt the same
scheme in varbincode.
The `directories` crate unconditionally and eagerly tries to spawn
`xdg-user-dir` for all possible directories that it might be asked
about. This is relatively expensive and undesirable.
Shift to the `dirs` crate instead, which doesn't seem to need
to run `xdg-user-dir` at all.
Maintain these probed dirs as singletons via lazy_static.
