Allows specifying the precise dpi to use on a per-screen basis:
```lua
return {
dpi_by_screen = {
["Built-in Retina Display"] = 144,
},
}
```
The screen names are the same as those returned from
`wezterm.gui.screens()`.
Changing either `dpi` or `dpi_by_screen` in the config will now cause
the window to be immediately resized/adjusted to the changed dpi
override.
Ultimately, I'd like to deprecate `dpi` in favor of `dpi_by_screen`,
but can't do that until this functionality is ported to windows, x11
and wayland.
refs: #4096
The approach we were using previously was to ask macOS for the fallback
font list, but it didn't include the correct fonts for certain
codepoints.
Switch to using an alternative API that asks macOS which font to use for
a specific codepoint.
refs: #4099
This is primarily to improve the chances of displaying an arbitrary
image without resorting to additional external tools, that may be
difficult or impossible to install.
refs: #3716
refs: #3264
otherwise, the termwiz line reader can become confused and
fail to recognize key presses like `(` which have SHIFT and LEFT_SHIFT
set.
refs: https://github.com/wez/wezterm/issues/3999
Factor out the probe_screen_size method from the Terminal
trait and put it into a ProbeCapabilities struct.
This makes it easier to introduce other sorts of probed
information without making the Terminal trait grow all sorts
of additional methods.
A Terminal may choose not to support probing, which it cannot
if it doesn't have Read + Write handles to an underlying terminal
(such as some special cases in wezterm).
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
We can now delegate to the new mlua helpers for a lot of this stuff.
We do still take first dibs on printing userdata so that we can use
our dynamic data interpretation when available, but otherwise, we
can now show reasonable information about things like builtin file
objects, and include the pointer address of things like functions
to help disambiguate them when printing them.
refs: #3849
refs: https://github.com/khvzak/mlua/issues/291
The original thinking was that it would be quicker to reuse
the existing release mode deps, but I'm not sure if that is
still true, so let's test it to see.
At the time of writing, the test phase takes 8-12 minutes depending
on the OS, with most of that being compilation.
Feels safest to do this until we can make a smoother fallback
experience for webgpu.
I will revert this after tagging the release so that nightly
runs webgpu by default.
Relocate the helper function to mux-server-impl and have both the GUI
and the mux server call it at the appropriate times.
Introduce default_mux_server_domain which is used instead of
default_domain in the mux server. This is to avoid recursive
cycles when starting up the mux; we don't want the default
domain to be a unix client that connects to our selves because
we'll try to connect to ourselves, then in act of handling that
spawn in the default domain and try to connect to ourselves and
repeat.
refs: https://github.com/wez/wezterm/issues/3907
Previously the same emoji was able to appear multiple times in the
CharSelect modal for emoji input, because one emoji might have multiple
aliases. In fact, often the aliases have similar names, making it
especially likely that a fuzzy match matches multiple aliases at the
same time.
The same Unicode char may even match multiple times both as
Character::Unicode as well as a Character::Emoji.
To make the deduplication easy, store the results in a hash map instead
of a vector. We use the glyph as the key of the map to get free
deduplication.
Only update the mapped value, if a duplicate entry would improve the
score.
Performance-wise this is pretty much identical to the previous state.
We do see minor performance regression for very large n - granted, this
is expected as we do more work - but the use of the HashMap covers up
for a large part of it.
If the user types more than 3 characters, the performance is absolutely
identical. For less than 3 characters, the performance was unacceptable
anyway (700 ms before this patch, 800 ms after this patch on my system).
Here is a side-by-side comparison for a user iteratively typing the
query "no-evil":
# Before After
1 718.361276ms 837.612275ms
2 719.532450ms 816.348394ms
3 349.625101ms 369.726458ms
4 356.349671ms 354.367768ms
5 363.862194ms 361.985546ms
6 372.339582ms 370.022932ms
7 381.123785ms 378.349672ms
In fact, for small n, the hash map seems to perform even slightly better
than the vector.
For large n we need to optimize the performance anyway, as both 700ms
and 800ms are unacceptable.
Thus, this is worth it for the benefit of Unicode symbol deduplication.
