Previously the same emoji was able to appear multiple times in the
CharSelect modal for emoji input, because one emoji might have multiple
aliases. In fact, often the aliases have similar names, making it
especially likely that a fuzzy match matches multiple aliases at the
same time.
The same Unicode char may even match multiple times both as
Character::Unicode as well as a Character::Emoji.
To make the deduplication easy, store the results in a hash map instead
of a vector. We use the glyph as the key of the map to get free
deduplication.
Only update the mapped value, if a duplicate entry would improve the
score.
Performance-wise this is pretty much identical to the previous state.
We do see minor performance regression for very large n - granted, this
is expected as we do more work - but the use of the HashMap covers up
for a large part of it.
If the user types more than 3 characters, the performance is absolutely
identical. For less than 3 characters, the performance was unacceptable
anyway (700 ms before this patch, 800 ms after this patch on my system).
Here is a side-by-side comparison for a user iteratively typing the
query "no-evil":
# Before After
1 718.361276ms 837.612275ms
2 719.532450ms 816.348394ms
3 349.625101ms 369.726458ms
4 356.349671ms 354.367768ms
5 363.862194ms 361.985546ms
6 372.339582ms 370.022932ms
7 381.123785ms 378.349672ms
In fact, for small n, the hash map seems to perform even slightly better
than the vector.
For large n we need to optimize the performance anyway, as both 700ms
and 800ms are unacceptable.
Thus, this is worth it for the benefit of Unicode symbol deduplication.
* Change aliasing to exact matches of the color data.
* Don't "GC" away schemes that are no longer reachable from aggregators;
just because they are no longer listed elsewhere, doesn't mean that we
should remove the name/scheme from wezterm if it was already made
available in an earlier release.
refs: #3831
This is fixing a regression introduced by the fix for #2845.
The resolution for this is relatively straightforward, but took a bit
of effort to plumb.
Previously:
* CTRL/ALT/SUPER-modified keys with no explicit expansion would end
up just taking the US layout version of the key. That worked well
for the intended problem with non-latin layouts, but for eg: German
layouts it caused expansion to totally the wrong thing
Now:
* CTRL/ALT/SUPER-modified keys which effectively expand to non-ascii
text (eg: cyrillic "Es") now take the equivalent key press from the
US layout (which would be "c" in the "Es" case). For European
layouts this heuristic seems to avoid unexpected effects, but could
do with some validation from native users.
To support this, the xkb code splits the `Keyboard` struct out from
some of the higher level logic and introduces a `KeyboardWithFallback`
struct that is built out of the user-selected keyboard layout, and
the fallback keyboard. Now the fallback keyboard is fed the same
key inputs as the selected keyboard to correctly model the key
combinations.
refs: #3610
refs: #3933
ssh connection or host authentication errors would not be displayed
when the config was in its default exit_behavior=Close state.
This commit introduces some plumbing to allow a pane to override
the effective exit_behavior value, so that ssh sessions can now
rewrite it to CloseOnCleanExit while they are in the process
of connecting.
refs: #3941
An older version of proc-macro2 used by many crates doesn't compile
on nightly rust any more. It doesn't look like we need nightly
rust for cargo-fuzz any more, so try using stable rust instead.
On Wayland, copy mode often doesn't actually update the clipboard.
Specifically, it only works one time after a pointer enter or pointer
button event, then doesn't work again until the next event.
This is because the Wayland protocol serial number in
CopyAndPaste::last_serial is only updated by pointer enter and pointer
button events. So, subsequent copies using only the keyboard reuse the
same serial number and get ignored. last_serial used to be updated for
keyboard events, too, but that was (accidentally?) dropped in commit
0a00ffe98b.
Commit 0a00ffe98b also added another
last_serial to WaylandConnection which is updated for keyboard events
but isn't used anywhere as far as I can tell.
So, to fix this bug, let's get rid of CopyAndPaste::last_serial and
replace it with WaylandConnection::last_serial, which is now updated for
pointer and keyboard events.
closes: #3843
Error message I've been seeing the past couple of days:
Unable to resolve appearance using xdg-desktop-portal: invalid value:
string "()", expected at least one field signature between `(` and `)`:
invalid value: string "()", expected at least one field signature
between `(` and `)`
