When we decode a key event from X11 into a `KeyCode::Char(_)` variant,
that result has already factored in the result of the SHIFT modifier
state.
That makes SHIFT largely useless for unicode keys; we do want to
preserve the SHIFT modifier for keys such as the arrow keys.
This commit removes SHIFT from the `KeyEvent::modifiers` for
`KeyCode::Char(_)` variants so that those modifiers don't get
in the way of keymap lookups.
refs: https://github.com/wez/wezterm/issues/394
I didn't recreate precisely the situation in the issue, but I
tried pressing both `AltGr 8` and `CTRL ALT 8` with a DEU
layout active and both now result in `[` being emitted.
refs: #392
80214319ae broke the use of RUST_LOG to
turn up trace logging.
This commit refactors logger initialization into the env-bootstrap crate
so that it is centralized, and adopts the use of `WEZTERM_LOG` to
override the default logging filters, rather than `RUST_LOG`.
Make pane, tab, window close confirmations use the same core function.
Make that function accept mouse input so that closing the window with
a mouse click doesn't require switching to the keyboard to confirm
the close.
refs: #280
61c52af491 accidentally broke key
assignments that included ALT on macOS (and perhaps others?) because
LEFT_ALT or RIGHT_ALT were also now being passed through to the
keymap lookup, preventing a direct match.
This defaults to None, taking the default from the freetype library.
You can select an integer value to tell the library to use an
alternative version.
Versions that are available in the build used by wezterm are 35, 38 and
40.
See https://freetype.org/freetype2/docs/subpixel-hinting.html for
more information.
Revise logging so that we use info level for things that we want
to always log, and adjust the logger config to always log info
level messages.
That means shifting some warning level logs down lower to debug level so
that they aren't noisy.
closes: https://github.com/wez/wezterm/issues/388
The default is 1.0. `line_height` is used to scale the effective
cell height, increasing the amount of space between font baselines.
refs: https://github.com/wez/wezterm/discussions/387
I noticed that wezterm is picking up garbage from gnome too,
so let's trigger the random fd closing function on all unix
systems.
It turns out that iterating the entries in /dev/fd works on
BSD and Linux which is nice.
My original goal was to update to allsorts 0.5 but the API
changes are significant and not clearly described.
To make that transition easier, the prior commit moved the shaping
logic into our allsorts shaper module, leaving the name parsing
here in parser.rs.
This commit now replaces that logic with ttf_parser, which is
potentially faster (there's more emphasis on optimal code in that
crate than in allsorts) but definitely simpler.
It's not a slam-dunk transition: ttf_parser doesn't know how to
decode MacRoman encoded text, so there's a bit of logic borrowed
from allsorts here to handle that.
I'm gradually improving snapshot testing macro devx in k9 and preparing
to ship v1. Before i do this i'm changing the inline snapshot macro to be
just `snapshot!()` that takes `Debug` trait an an arg and figures out
serialization of it.
This helps keep the config object a bit smaller and the trace logging
output less verbose.
We now memoize the effective palette in the config, which should shave
off a little bit of time in the renderer.
The root cause of this was that I'd added a fontformat=TrueType
constraint to the fontconfig pattern and since fontconfig has
fontformat=CFF for Hasklig, it wasn't the primary font candidate.
When I cut out redundant fontconfig checks in
ee1d84829a it meant that we'd never
"see" the hasklig result that turns up ~20 or so fonts into the
fallback list.
This commit removes the TrueType constraint so that the results
are ranked correctly again.
I've also switched the main font lookup path to using an alternative
font config API that returns only the best match as that more closely
aligns our intent in this function; originally, fallback was intended
to be handled in this code path, but these days it has its own separate
method.
closes: https://github.com/wez/wezterm/issues/383
refs: https://github.com/wez/wezterm/issues/379
font-config can return very long lists of fallback fonts like:
```
2020-12-16T16:23:13.306Z TRACE wezterm_font::locator::font_config > query font-config for Pattern(Operator Mono SSm Lig Medium,DejaVu Sans,PT Sans,PT Sans Caption,Bitstream Vera Sans,DejaVu Sans,Verdana,Arial,Albany AMT,Luxi Sans,Nimbus Sans L,Nimbus Sans,Nimbus Sans,Helvetica,Nimbus Sans,Lucida Sans Unicode,BPG Glaho International,Tahoma,Comfortaa,Montserrat,URW Gothic,Nimbus Sans,Nimbus Sans Narrow,Carlito,Droid Sans,Nachlieli,Lucida Sans Unicode,Yudit Unicode,Kerkis,ArmNet Helvetica,Artsounk,BPG UTF8 M,Waree,Loma,Garuda,Umpush,Saysettha Unicode,JG Lao Old Arial,GF Zemen Unicode,Pigiarniq,B Davat,B Compset,Kacst\-Qr,Urdu Nastaliq Unicode,Raghindi,Mukti Narrow,malayalam,Sampige,padmaa,Hapax Berbère,MS Gothic,UmePlus P Gothic,Microsoft YaHei,Microsoft JhengHei,WenQuanYi Zen Hei,WenQuanYi Bitmap Song,AR PL ShanHeiSun Uni,AR PL New Sung,MgOpen Modata,VL Gothic,IPAMonaGothic,IPAGothic,Sazanami Gothic,Kochi Gothic,AR PL KaitiM GB,AR PL KaitiM Big5,AR PL ShanHeiSun Uni,AR PL SungtiL GB,AR PL Mingti2L Big5,ＭＳ ゴシック,ZYSong18030,TSCu_Paranar,NanumGothic,UnDotum,Baekmuk Dotum,Baekmuk Gulim,KacstQura,Lohit Bengali,Lohit Gujarati,Lohit Hindi,Lohit Marathi,Lohit Maithili,Lohit Kashmiri,Lohit Konkani,Lohit Nepali,Lohit Sindhi,Lohit Punjabi,Lohit Tamil,Meera,Lohit Malayalam,Lohit Kannada,Lohit Telugu,Lohit Oriya,LKLUG,Mingzat,Padauk,Nuosu SIL,FreeSans,FreeSans,Arial Unicode MS,Arial Unicode,Code2000,Code2001,sans\-serif,Roya,Koodak,Terafik,sans\-serif,sans\-serif,sans\-serif,ITC Avant Garde Gothic,URW Gothic,sans\-serif,sans\-serif,Helvetica,Helvetica Narrow,Nimbus Sans Narrow,sans\-serif,sans\-serif,sans\-serif:slant=0:weight=80:spacing=100:fontformat=TrueType) took 1.344155ms
```
In the context of that particular call, we only care about whether the
first result matches what we're looking up. The fallbacks are processed
separately in a different method.
Therefore, we can skip additional processing and save a non-trivial
number of milliseconds overall parsing/re-parsing them to verify
whether they are the one we wanted to match.
refs: https://github.com/wez/wezterm/issues/379
font-config can return a long list of fallback results for a given
font family, and we parse those to see if they match; once we've
found a match there's zero chance that that errort is helpful,
so break out of the loop.
Add some more trace logging to see if that helps.
refs: https://github.com/wez/wezterm/issues/379
in ab342d9c46 I started to rearrange how
the output processing thread works. It wasn't quite right, so this
commit tidies things up.
The main change here is that there is now back-pressure from the output
parser on the reader; if it is taking a while to parse the output then
we don't buffer up so much input.
This makes operations like `find /` followed immediately by `CTRL-C`
more responsive.
With this change, I don't feel that the
`ratelimit_output_bytes_per_second` option is needed any more, so it
has been removed.
This removes the ratelimiter from the mux pty output reader.
Instead, we now have two reader threads:
* One to perform blocking reads from the pty output and send them
to the other thread
* The other thread waits for data from the first, then tries to find
a newline character so that it can send 1+ lines of data to the
terminal parser. If it doesn't find any lines, it waits ~50ms for
additional data from the first thread to bundle together eg:
really long lines, or image protocol data. It will keep doing this
until no more data arrives within 50ms or until it finds a newline.
Once no more data arrives within 50ms, it sends whatever it has
accumulated and then blocks waiting for the next chunk
I tried a quick ctrl-c test with this; running `find /` and seeing
how easily interruptible it is, and it seems OK on my M1 mac.
I don't think we need the output rate limiter any more, but I'll
try this out on my bigger linux machine as well to see if that
feels as good.
With this change, `cat test-data/emoji-test.txt` no longer has wonky
spacing when it gets to the England flag at the bottom.
refs: https://github.com/wez/wezterm/issues/339
