This is a weird attribute TBH.
xterm seems to replace the cells with spaces: copying and pasting
results in spaces.
Kitty ignores it.
VTE doesn't render it but allows copying and pasting.
The latter is now also the behavior in wezterm.
This provides a means for more easily extending the default key
tables without forcing the user to recreate the entire config
for themselves.
wezterm.gui.default_keys is also added by this, but it is likely
not as useful.
There were two problems:
* We weren't correctly invalidating when the hover state changed
(a recent regression caused by recent caching changes)
* We'd underline every link with the same destination on hover,
not just the one under the mouse (longstanding wart)
Recent changes allow the application layer to reference the underlying
Lines directly, so we can restore the original and expected
only-highlight-under-the-mouse by switching to those newer APIs.
Adjust the cache values so that we know to also verify the current
highlight and invalidate.
I was a little surprised to see that this also works with mux client
panes: I was expecting to need to do some follow up on those because
they return copies of Line rather than references to them. That happens
to work because the mux client updates the hyperlinks at the time where
it inserts into its cache. The effect of that is that lines in mux
client panes won't update to new hyperlink rules if they were received
prior to a change in the config.
refs: https://github.com/wez/wezterm/issues/2496
Given this sequence:
ENABLE-UNDERLINE CRLF SGR-RESET
if the CRLF caused the terminal to scroll, the newly created line
at the bottom would be filled in with a "blank" cell that had
the underline attribute set.
That's because we're supposed to preserve the coloring in that
scenario, but we were also preserving other SGR attributes.
This commit explicitly clears out under, over and strikethrough
lines from these blank attributes.
refs: https://github.com/wez/wezterm/issues/2489
We were getting data like this back from harfbuzz:
shaped font_idx=0 "파인더에서 만든 폴더" as: [.notdef=0+448|.notdef=0+448|.notdef=6+448|.notde=6+448|.notdef=6+448|.notdef=15+448|.notdef=15+448|.notdef=21+448|.notdef=21+448|.notdef=27+448|.notdef=27+448|space=33+448|.notdef=34+448|.notdef=34+448|.notdef=34+448|.notdef=43+448|.notdef=43+448|.notdef=43+448|space=52+448|.notdef=53+448|.notdef=53+448|.notdef=53+448|.notdef=62+448|.notdef=62+448]
which had a series of discontiguous and repeated runs for the same
cluster/region, but due to a logic error, we weren't coalescing them
together and were passing somewhat nonsensical ranges to the
next font for shaping.
This commit "simply" ensures that we code the checks for codepoint==0
(the `.nodef` seen above) and the results are at least correct
for this particular case.
refs: https://github.com/wez/wezterm/issues/2482
ad9490ee8f unset SHELL from the
environment on startup which had the consequence of causing
`os.getenv("SHELL")` to return `nil` when used in the config file.
Rather than simply restoring SHELL env var, recognize that reading
the environment from a long lived process is prone to seeing
stable environment forever.
We already compensate for this in the pty crate's understanding
of the base environment, so this commit patches `os.getenv`
and replaces it with our own imlementation that uses that same
logic.
The base environment logic has been extended to set SHELL from
the passwd database to round things out.
refs: https://github.com/wez/wezterm/discussions/2481
There are caveats to determining this, but when we think
password entry is enabled, switch the cursor to the font-awesome
lock glyph instead of the normal cursor sprite.
fa_lock is used because it is monochrome and can thus be tinted
to the configured cursor color, and it respects blinking/easing.
refs: https://github.com/wez/wezterm/issues/2460
I've had a couple of people report issues like
https://github.com/wez/wezterm/issues/2378 recently, and we can avoid
this class of problem by unsetting SHELL at proces startup, so that's
what we do.
CTRL-SHIFT-U is a new default key assignment for this new modal.
It opens up a fuzzy searchable browser that defaults to showing
emoji/emoticons. The category can by cycled through the suggested
emoji categories using CTRL-r. Unlike the system emoji palette,
wezterm includes a category for nerdfont symbols, and another
that is a list of all unicode codepoint names, so you should be
able to browse for pretty much any codepoint you can think of.
The modal also allows fuzzy searching based on:
* The official unicode name
* The github shortcode
* codepoint value in hex
so if you know the codepoint value but not the name, you can
still find a way to input what you're looking for.
Pressing Enter will copy the selected item to the clipboard
send it to the active pane, and cancel the modal. You can therefore
repeat the insert by simply pasting.
I plan to add frecency to this in a later commit: that way the
frequently/recently used selections will show in a category of
their own and make it easier to re-input them.
refs: https://github.com/wez/wezterm/issues/2163
Inspecting the wezterm process with `lsof -p`, before and after closing
a pane with `CloseCurrentPane`, the same number of unix domain sockets
are open, which is bad.
This commit tries a bit harder to clean things up: if we got a process
exit condition we now remember that we had it, and, while processing
the IO for that channel, if we have no data for stdout or stderr
(respectively) and the channel exited, we close our end of the
socketpair to encourage EOF to be detected on the other end.
This is sufficient to restore the number of open files to the same
number wezterm had opened prior to opening that pane.
@chipsenkbeil: this might possibly be a factor in the issue you
reported, but I haven't had time to really dig into that yet!
refs: https://github.com/wez/wezterm/issues/2466
refs: https://github.com/wez/wezterm/issues/2456
It can have some surprising effects, so leave it at the basic logical
composition of cwd + relative rather than physical.
refs: https://github.com/wez/wezterm/issues/2449
