We need access to the underlying raw/physical key in order
to correctly encode in some modes, so we need the full KeyEvent
struct for that.
Move the encoder up so it sits alongside the win32 input mode
encoder.
This should give us better results for both shifted/unshifted
and the "base layout" (US english) representations of a number
of keys.
Note that this is still not 100% technically correct: the unshifted
keys require knowledge of the keyboard layout that we don't have
at this OS-independent layer.
Right now we're assuming a US layout to unshift punctuation, which
is not right if you're not using that layout. To resolve that,
more work is needed on each OS to be able to extract that information
and then to store it in the KeyEvent.
refs: https://github.com/wez/wezterm/issues/3479
refs: https://github.com/wez/wezterm/issues/2546
Previously, the config crate would get rebuilt each time the
git state changed, which has a lot of fan out and makes the build
take longer than it really needs to.
This commit breaks out the version changing stuff to its own crate
and then provides a runtime mechanism for assigning the version
information back into the config crate.
The env-bootstrap crate is responsible for setting that up.
The termwiz Modifiers type isn't the right one!
Use the input layer types instead, and then we get the correct
string formatting.
refs: https://github.com/wez/wezterm/issues/3434
The server-side ownership of the palette is a stumbling block for
many users, so let's fix it.
This commit allows the client to pass its configured palette to
the server when it connects, and when the config is changed.
That palette takes precedence over the palette from the server config.
However, if the remote application uses any escape sequences that
redefine the color palette, the color palette that was active at
that point in time is forked and use as the basis, and will remain
the active palette until the palette is reset via escape sequences.
refs: https://github.com/wez/wezterm/issues/2686
refs: https://github.com/wez/wezterm/issues/3397
This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
If you haven't assigned `config.ssh_domains` to something else,
this commit will populate it from the hosts it finds in your
ssh config file.
First it will emit no-multiplexing entries that allow ad-hoc
ssh connections.
Then it will emit wezterm multiplexing enabled versions of those
entries.
Lua appears to populate package.path to something based on the
executable path on windows, but since it uses msvcrt in ANSI mode,
that string is encoded in whatever 8-bit MBCS is configured by
the host system ACP setting.
Rust expects that to be UTF-8, but Windows doesn't guarantee it.
This commit updates the manifest for wezterm-gui to tell Windows
that it wants its ACP to be set to UTF-8 prior to launch, which
should resolve this situation for the GUI.
This commit also introduces a more cut-down manifest for the
console-subsystem executables that also use the lua config layer,
which should hopefully resolve this issue for them.
This commit was authored on a mac, so fingers crossed that it
even compiles properly on windows!
refs: https://github.com/wez/wezterm/issues/3390
It's a tremendous PITA for the user to do this at the system level on a
mac, where it is sorely needed. This commit allows raising to a desired
minimum level, but won't decrease from an already larger soft limit.
refs: https://github.com/wez/wezterm/discussions/3353
- v2.0 no longer derives a bunch of traits (Debug, Clone, Copy, PartialEq, Eq)
by default, so I manually derived them.
- It also changed the snapshot results so I updated them:
An empty bitflags struct is no longer displayed as `None` but as
`BitFlags(0x0)`.
- `bits` is no longer a field but a method so I added the missing
parenthesis.
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
The upstream open crate keeps making stuff async/blocking/not-working on
windows, so this is a step towards removing this dependency.
refs: https://github.com/wez/wezterm/issues/3288
This allows the decoder thread to live only long enough
to decode the full set of frames; we can then store the
leases in memory and pull them in only when there is
a cache miss.
refs: https://github.com/wez/wezterm/issues/3263
Adopt the new blob lease layer to storing and referencing
image files.
This reduces the number of open files needed when
images are being displayed in the terminal.
refs: https://github.com/wez/wezterm/issues/3263
Continuing from the previous commit, this shifts:
* In-memory data -> temporary file
* Image decoding -> background thread
The background thread asynchronously decodes frames and
sends them to the render thread via a bounded channel.
While decoding frames, it writes them, uncompressed, to
a scratch file so that when the animation loops, it is
a very cheap operation to rewind and pull that data
from the file, without having to burn CPU to re-decode
the data from the start.
Memory usage is bounded to 4 uncompressed frames while
decoding, then 3 uncompressed frames (triple buffered)
while looping over the rest.
However, disk usage is N uncompressed frames.
refs: https://github.com/wez/wezterm/issues/3263
This makes decoding animation frames a lazy operation, but it
comes at the cost of needing to re-decode the image from scratch
when it loops, because the image crate doesn't provide a way
to rewind its frame iterator.
That initial decode can have a significant time cost; a small
webp file consistently takes 150ms to decode, which is too
much to do inline in the render thread.
Next steps will be to move that cost off the render thread.
