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.
https://github.com/wez/wezterm/issues/19 is a case where a user
runs in this; it seems particular to their opengl implementation
so I can't reproduce it locally.
@Lompik suggests that this resolves the issue, and it doesn't seem
to hurt, so let's apply it!
on macos we were receiving unicode text in addition to the scan codes.
This is mostly undesirable, except when it's not
(see https://github.com/wez/wezterm/issues/18)
This diff ignores the unicode input stream and manually decodes
the keys from an english keyboard.
This allows choosing between X11 and Glutin, which simplifies some
conditional code and allows some short term flexibility on unix
systems. However, what it really opens up is running a future
headless server mode (think: tmux).
This change comes with the cost of temporarily breaking creating
a new window on x11.
