Event handling #2
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since an event not matched by the `cond' form now goes in `unread-post-input-method-events' rather than `unread-command-events', turn on the appropriate argument of the initial `read-event' (INHERIT-INPUT-METHOD) to make sure the event doesn't get queued without its input method ever being handled.
As suggested in section 21.7.15 of the elisp manual, handle keyboard events internally as vectors across the board, rather than preferring strings when possible. This commit, in combination with the one before it, fixes syl20bnr#51: `this-command-keys' returns a vector for most key sequences, so (for instance) the expression (equal (this-command-keys) "π") is always nil.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commits 130219b and 819f1ee, which fixed the macro-record bug, introduced another bug which only manifests itself when using an alternative input method. This branch fixes that, while also resolving a different problem with input methods that already existed in the upstream (see syl20bnr#51).
Say your escape sequence is
jk. Do aC-\to switch to the input methodprogrammer-dvorak. (Be advised: this only translates keystrokes in evil's insert and replace modes, and it doesn't translate any key-modifier combinations in any mode.)Now you'd think you could trigger an escape by typing "jk" with the physical keys C and V -- or, failing that, at least by hitting the now-translated physical keys J and K. Instead, the physical key sequence you need is their bastard child CK. What's worse, if you hold down the C key, and if your OS passes repeated keystrokes to Emacs fast enough, the string inserted into the buffer is "jcjcjcjcjcjcjc".
Problem:
evil-escape-pre-command-hook, when waiting for the second character of the escape sequence, bindsevtwith a call toread-eventthat doesn't request input method processing. This means it matches against the escape sequence based on an untranslated keystroke. It also means it pushes the untranslated keystroke straight onto the post-input-method event queue, from which its binding is looked up directly.Just telling
read-eventto handle the input method is enough to fix the behavior. And this doesn't reintroduce the earlier bug; the change in argument toread-eventleaves macro recording alone. The extra processing step doesn't make any discernible difference, either perceptually or in the profiler. (The pre-command hook is effectively a deep inner loop if you're doing something like scrolling, but the call toread-eventnever happens unless the last event was the first half of the escape sequence.)As for the upstream bug: that was caused by
this-command-keysbeing so obnoxious as to return different sequence types depending on the values of the elements (!). All salient details are in the commit message.