Open user202729 opened 3 years ago
Same issue with xdotool, so not a Plover issue.
note: This doesn't happen "by default" with xdotool because xdotool uses the Unicode keysym (U1234) for characters > 0xFF.
However if there's an existing character equal to ∧
in xmodmap then xdotool will not be able to type it.
Same issue: https://unix.stackexchange.com/questions/362164/terminal-does-not-accept-some-typed-in-unicode-characters (with no clear solution)
Plover could have a workaround by always creating Unicode keysym, but it might have other problems.
This could be implemented by clearing the dictionary KEYSYM_TO_UCS
and UCS_TO_KEYSYM
-- edit the source code or run this
(or use my plugin https://github.com/user202729/plover-startup-py)
as a temporary solution:
from plover.oslayer import xkeyboardcontrol;
xkeyboardcontrol.KEYSYM_TO_UCS.clear();
xkeyboardcontrol.UCS_TO_KEYSYM.clear();
XLookupString
documentation have (emphasis mine)
Otherwise, the KeySym is mapped, if possible, to an ISO Latin-1 character or (if the Control modifier is on) to an ASCII control character, and that character is stored in the buffer.
which means that it's only compatible with 8-bit characters.
Most likely a xterm bug. (it could use Xutf8LookupString
instead)
Useful links: https://unix.stackexchange.com/questions/358371/keyboard-input-encoding
Probably better to reopen.
It's still preferable for Plover to imitate xdotool's typing strategy (if create new mapping, then make it map to the Unicode character) in order to be slightly more compatible.
Note
This might be a xterm bug rather than a Plover bug, because:
xdotool
instead have the same issue.but this one Plover can workaround (although with more configuration options etc.) by always using the Unicode keysym when defining new keysyms rather than the "special" ones.
Describe the bug
Title
To Reproduce
Steps to reproduce the behavior:
∧
,⌊
or∘
.Operating system
Similarly, if ✗ is typed, xterm receives ☒ instead.