On MacOS 15 (Sequoia) and later,
Wezterm.app should ask for a LocalNetwork entitlement by default.
This fixes mysterious network failures (eg: 'no route to host') when:
- Wezterm is a toplevel process (ie: not a child of a process
that already has LocalNetwork entitlement, like Terminal)
- A shell running inside Wezterm executes a process which accesses the network,
but does not itself already have a LocalNetwork entitlement,
eg: /etc/profiles/per-user/$(whoami)/bin/ssh
for ssh installed by nix home-manager.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
On bash it's possible to hit ^C before we remembered the PS1 which would
cause the shell to end up with an empty PS1, making it unclear that the
^C actually worked as there is no prompt left.
I'm not sure I understand the need to mess with the variable every time
(could just add the OSC codes if not already present and never remove
them?), but at least make it so we don't end up with an empty prompt
line by checking the saved value isn't empty.
Otherwise it is just hidden forever. We can't use the proper declarative
interface, because we are faking quite some stuff for "-e", so instead
we mention it explicitly in the help output.
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.
