Procedure is:
* Download the `NerdFontsSymbolsOnly.zip` release asset
* Extract the font into assets/fonts
* Run the codegen to update nerdfonts_data.rs:
`cd termwiz/codgen ; cargo run`
* Apply formatting: `cd ../../ ; cargo +nightly fmt`
* Update the list of symbols in the docs:
* edit `docs/config/lua/wezterm/nerdfonts.md`
* delete the table
* Run the embedded vim command that will regenerate the table
refs: https://github.com/wez/wezterm/pull/4656
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
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
base arch linux installation doesn't include `hostname` binary as it's part of
a separate `inetutils` package, use systemd `hostnamectl` which is available in
all systemd-based distributions
Implement an app delegate to receive a callback when the system
requests that we open `.command` files, and then ask the mux
layer to spawn a window for it and execute it via the shell.
Also allow handling `.sh`, `.zsh`, `.bash`, `.fish` and `.tool`,
per kitty.
refs: https://github.com/wez/wezterm/issues/2741
refs: https://github.com/wez/wezterm/issues/2871
In a56904e40d the desktop file was patched
to use "wezterm start" instead of "wezterm". As an unneeded addendum
that patch also included the unnecessary addition of ending command-line
parsing by passing the "--" option at the end.
As it turns out, some consumers of wezterm's desktop file want wezterm
to parse command line flags. For example KDE's kio passes the whole
cmdline via the "-e" flag, because it is widely used for most terminal
emulators as the primary mean of passing the cmdline.
To solve this we remove the unneeded "--" again, because we now also
support the "-e" option.
After all, all trailing arguments will automatically be parsed by
wezterm as the cmdline of the program to run.
The only sideeffect of this change is that we now cannot longer start
programs that share a name with a "wezterm start" option, for example if
the user has installed an executable at /usr/bin/--always-new-process
then this edge case will not work anymore.
Given that this would be an extremely unlikely scenario, it makes more
sense to improve compatibility by supporting the usecase of passing the
cmdline with the "-e" flag.
refs: #2622
refs: #2271
refs: https://bugs.kde.org/show_bug.cgi?id=459616
As explained in the comments, the Nautilus 4.0 API just passes files without the window object (which was unused anyway). This small fix keeps compatibility with the 3.0 API and checks the number of arguments.
Would be really nice if you could make this count towards hacktoberfest as well!
I was going to upgrade to the unicode 15 font, but in testing this I
decided that the logic is slightly complex and the glyphs are often
difficult to see at most terminal font sizes, which generates questions
from users, so just fall back to notdef.
They pass this:
```
flatpak run --env=G_DEBUG=fatal-criticals org.freedesktop.appstream-glib validate assets/wezterm.appdata.xml
assets/wezterm.appdata.xml: OK
```
but break when building a flatpak
This commit allows wezterm to spawn programs into the host rather
than in the container environment.
It feels weird that it is so trivial to "break out" of the container
sandbox, but I'm not complaining.
There are some unfortunate consequences:
* there is no `wezterm` installed on the host, so no ability to `wezterm
cli` to control it from other apps
* The unix domain socket is scoped inside the sandbox, so there's "no
way" for `wezterm cli` to reach inside anyway.
But: with this, it is at least usable to start a flatpak and open a
shell.
refs: https://github.com/wez/wezterm/issues/2229
Run `ci/flatpak.sh` to build a flatpak of just the gui.
Run it via flatpak run org.wezfurlong.wezterm
refs: https://github.com/wez/wezterm/issues/2229
Thanks to: @Imxset21
