The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
The warnings were not noticed in the original PR.
Those warnings were actually errors.
Promote warnings to error in the mapping logic to prevent
this sort of thing from slipping through in the future,
and fixup the errors.
refs: #3935
refs: #3937
Note that this also does not respect dpi_by_screen; this is for
consistency in behavior and reported values.
Once we can produce the correct overridden value in
dispatch_pending_event, we can update these functions to return
the same data.
refs: #4096
This is a baby step towards handling dpi_by_screen.
I don't want to do the actualy per-screen stuff here;
it touches stuff around the edges of SCTK and there is a pending,
significant, rewrite of that code needed to upgrade to a more
recent version of SCTK + wayland-protocols, and I don't want to waste
my effort on the intermediate state.
https://github.com/wez/wezterm/issues/3996#issuecomment-1636830740
refs: #4096
Maintain a cache of the positions of the various named screens,
and use that to resolve the screen of the current window, and
from there we can resolve the correct dpi_by_screen screen.
Make dpi and dpi_by_screen config changes generate a resize
event with the updated dpi.
refs: #4096
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
