Part 1: letting Qt help At present, the Qt gui code knows only whether a keystroke is bound somewhere. However, a relatively minor refactoring of (the helpers of) k.masterKeyHandler should allow the Qt event filter to determine whether a binding actually exists for the keystroke *in the current pane*.
This information would allow eventFilter to pass all "actually" unbound keys on to the gui. In particular, this would allow Leo to bind arrow keys in the outline pane, while *unbinding* arrow keys in the body pane. This would be the easy way to fix several nasty cursor bugs. As I write this, I see that this scheme requires the Qt gui to support the event_generate function at least for Qt Key events. This is necessary to implement the next-line, prev-line and similar commands. In other words, if Leo isn't going to do these commands itself, there must be a way to pass on a request for these commands to Qt events. So the first step is to make g.app.gui.event_generate work at least for keystrokes representing arrow keys. Note that most of Leo knows only the *Tk* names for these keystrokes, so the Qt gui will likely have to translate the Tk to the Qt name. This should be doable, given the variety of translation tables that exist. Part 2: A clean divide between key binding and key handling. A few days ago I realized that there is a (mostly) clean separation between two parts of the key-handling code: 1. The *binding* translates the Tk-named bindings into various tables used by k.masterKeyHandler and its helpers. This part is horrendous, but it probably will never have to change. 2. The *lookup* part associates bindings with commands. This is what k.masterKeyHandler really does. This Aha means that we don't have to worry much, if at all, about the complications in the binding part. Although k.masterKeyHandler is complex, the recent and contemplated refactorings are localized, and they are not, in fact, all that difficult in concept. This is important, because future enhancements for vim will be to the lookup part, not the binding part. Part 3: Simplifying repeat counts I recently spent some time on the universal-arg code. This is inspired by Emacs, but it seems preposterously complex to me. Instead, it seems more natural to allow (some) commands to be prefixed by a repeat count, as in vim: 5 next-line or 5 j or 5 <down-arrow> This is conceptually much cleaner than the universal arg code. Moreover, the obvious place to handle numeric prefixes is in k.getArg. This method could set a global repeat count and call commands repeatedly if necessary. It probably would be wise to have a table of commands for which a repeat count makes sense, but that's a nit. I hadn't intended to write so much just now, but so it goes...Anyway, improving Leo's key handling is important for vim, and I intend to get this done this year. As always, your comments are welcome. Edward
-- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
