I have begun work on #1269 <https://github.com/leo-editor/leo-editor/issues/1269>: Better/faster key handling. I'll do #1269 in two phases:
- Phase 1: refactor and simplify key-handling code. - Phase 2: Use *binding dicts* to associate functions with keystrokes. This Engineering Notebook post covers only phase 1. Here, I'll discuss the present state of Leo's key-handling code, and ideas for refactoring it. *Background* Leo's key handling code is complex. Some of this complexity is intrinsic; some is self-inflicted. Inspired by Vitalije's ideas, I now see two related problems with the code: 1. Important methods have too many kwargs (keyword arguments). 2. Important methods don't have a clear purpose. This makes sense. A method with too many kwargs does too many things. There is no need to be hard on myself. Parts of the code are ancient. I wrote this code without cff. Without cff, it would not be possible to refactor the code. *Essential tasks* I have spent several hours reviewing the results of dozens of cff searches. I now see more clearly the overall shape of what the to-be-refactored code must do. There are two intertwined tasks: 1. Dispatch commands based on incoming keystrokes. 2. Dispatch commands (usually by name) by scripts and plugins. c.k.simulateCommand usually does this. These tasks are similar but *not* identical. When handling actual keystrokes, Leo must handle *keystroke-only tasks*, such as abbreviations, lossage, key-state (support for the minibuffer), and user-defined modes. c.k.simulateCommand need not (*should *not) do such tasks. *The simplest things that could possibly work* An early iteration of these ideas considered handling keystroke-only tasks using binding dicts. A little thought shows that it would be much easier to add special cases for such tasks in k.masterKeyHandler or some other method. Indeed, k.masterKeyHandler isn't all that bad. It pretty much already handles keystroke-only tasks. The actual problems *mostly* revolve around kwargs. I can't say anything more here; the details are overwhelming. *Summary* Refactoring Leo's key-handling code is worth a lot of work. cff makes this refactoring possible. Two tasks will drive the refactoring: removing kwargs and clarifying the purpose of fundamental methods. The notion of *keystroke-only tasks* clarify what must be done. Phase 2 will primarily involve a rewrite of k.getPaneBinding. This phase is independent of phase 1, and might even be omitted. All questions and comments are welcome. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/2c9fda3d-c726-45e0-85f4-0338a0132872%40googlegroups.com.
