This is useful (essential!) for fixing up the default auth sock
under gnome, as we do not have a way to do that via whatever
logic may be present in the shell startup files.
This is done with a wezterm twist: not only is the auth sock forwarded,
but the mux on the remote end will automatically maintain a symlink to
point to the auth sock of the most recently active mux client, and set
SSH_AUTH_SOCK to that symlink so that your remote panes should always be
referencing something sane.
refs: https://github.com/wez/wezterm/issues/1647
refs: https://github.com/wez/wezterm/discussions/988
This enables users to override the normal invocation completely,
which is helpful for example when connecting into a gui from
a remote host.
I was wondering why prefer-mux was in here, and my commit message
from 7afc9e4d56 suggests that I
hit an issue where the gui wasn't running and where I didn't care
because I wanted to hit the mux.
I think that makes it a little awkward to blanket remove the
--prefer-mux flag, but for those that don't want it, they should now
be able to configure to allow connected to the gui
```
ssh_domains = {
{
name = "shortname",
remote_address = "hostname",
override_proxy_command = "wezterm cli proxy",
},
},
```
dependabot is trying to update pulldown-cmark, but it won't
work because the API has changed.
The update window is not enabled by default and I don't think
anyone uses it anyway, so let's just remove it and have less
code to compile and maintain.
closes: https://github.com/wez/wezterm/pull/4964
It used `::default()` rather than `::empty()` for the initial
set of bits, and since the two are no longer equivalent, it
prevented being able to assign `freetype_load_flags = 'DEFAULT'`.
refs: https://github.com/wez/wezterm/issues/4902
I meant to flip this back prior to cutting the most recent release,
and we've had a couple of issues already raised about WebGpu
and is transparency handling on Windows, and color/gamma.
I think I'll just leave this at OpenGL for a while, until WebGpu
catches up a bit better.
The cursor colors in gogh weren't imported quite right; this
fixes things up so that we use the background color together
with the cursor color from the scheme.
refs: https://github.com/wez/wezterm/issues/4257
* First step towards implementing #4226.
* Added InputSelector config options.
* Format + fix to prepare for PR to resolve#4226.
* Accept suggestion about pop().
* Fix typo.
* Tried fixing stuff from the feedback.
* Fixed typo.
* Fixed small mistake in docs.
* Small fix for label computation.
* Allow uppercase alphabet + add fuzzy_description.
* Minor cleanup.
* Use more standard alphabet (without j/k).
* Fixed docs after previous commit.
* Added key assignments to docs.
* Apply suggestions from code review (2 remaining)
* Updated arcording to feedback (added tests).
* Update docs (1 thing left to do)
* Added version details to the key table.
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Move the shortcode aliases out from the various emoji category
pages and into a new shortcode page.
Add variations, such as skin tones, to the different emoji
category pages.
Now we can optionally skip loading svg fonts, making our default
to continue to try to use them.
We don't actually support interpreting svg data, but we do now
support COLR v1 data which is found in some of those same fonts.
refs: https://github.com/wez/wezterm/issues/4148
The harfbuzz driven rasterization of COLR glyphs is superior to
my attept at a freetype driven rasterizer, so let's default to
the harfbuzz version.
This change means that the default for most regular glyphs is
freetype, but we'll use harfbuzz for COLR glyphs.
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.
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
