This wasn't hooked up right, partly because the glutin backend
bit rotted and I forgot that there was a future core.
This simplifies dispatching of requests that need to happen outside
of the gui loop control.
Remove detailed xcb select event hack
Only remove consumed "mod5" for now
which is AltGr.
Get actual modifiers from xkb.
it should enable 1:1 match with user's xmodmad
[clippy] allow keys deadcodes
handle mods & keys separately. Allows passing down `ctrl+2`
state.key_get_utf8 will interpret ctrl+2 (or @, space, ~) to 'ctrl \u{0}'
no need to wait for events.
+ Send delete as enum variant not by char value
Hook XKeysym to termwiz::KeyCode
prefer dealing with chars instead of utf8
Actually this breaks multi unicode characters .. such as J́
Others can be found with
perl -lane '/"\s+#/ && print' < /usr/share/X11/locale/en_US.UTF-8/Compose
Anyway we will need to return a Vec of chars for those.
cleanup
apply rustfmt
query locale via libc
I ran some numbers on the current build and we're a bit slower
today than we were when I last ran benchmarks. We've grown
more state in the CellAttributes that we manage so the profiler
shows those as relatively hot spots.
Performance is now on par with iTerm2 (w/ Metal Renderer) on macos
honestly now a little slower than vte based terminals, but still faster
than xterm (everything is faster than xterm!)
Alacritty is impressively holding its own at the front of the pack,
even with scrollback.
There's room for improvement in wezterm, but it still feels fine,
so perf isn't currently top of my list.
Closes https://github.com/wez/wezterm/issues/20
I've added dingbats to the fallback list on macos as that is needed
for some symbols we use in tools at work.
With that, and some tweaks for allowing for missing letter glyphs
when loading a symbol font as a fallback, we can make that the
default for macOS
Closes https://github.com/wez/wezterm/issues/5
This results in a less blurry display.
As a bonus, this lays down some plumbing for changing the font
size on the fly.
Refs: https://github.com/wez/wezterm/issues/2
There isn't really any reliable consistency in the virtual_keycodes
being set for simple keys or shifted keys, so we need to go all in
and add our own scancode processing as a fall back.
This makes it even harder to process unicode input, particularly
because we have no idea whether a ReceivedCharacter event will
follow.
