After releasing 4.8 final I sat in a nice hot bath daydreaming about what's next.
Clearly, much of 4.9 will be about bindings. Shift-Delete is merely the tip of a large iceberg. When I climbed out of the bath a few new thoughts appeared: 1. @mode is limited by the code orientation of Leo's core regarding the minibuffer. That is, each command that gets arguments from the minibuffer does so using *code*. Instead, we could follow how emacs works, and use a *description* of the desired args: http://www.gnu.org/s/emacs/manual/html_node/elisp/Using-Interactive.html This kind of scheme will allow Leo to "compile" descriptions in @mode nodes into the actual description used by the generalized minibuffer code. The essential idea is that I can design the description language to handle all the complexities required by vim bindings. This scheme will simplify all commands that use the minibuffer to get arguments. Of course, that will require some work, but the gain in simplicity and generality is worth it. 2. Much of the key-handling code is unavoidably complex (This is not the new thought ;-) However, it will help to add some standard terminology and a unified strategy for key bindings. Suppose we use the term **stroke** to mean a standardized representation of key bindings. I think the Emacs "spelling" of keystrokes is a good candidate: http://www.gnu.org/software/emacs/manual/html_node/emacs/Modifier-Keys.html#Modifier-Keys a- means alt, c- means control, etc. But notice the special cases and complications in the url just cited. More likely, I'll make the smallest possible tweaks to the existing code, with 'c' replacing ctrl, and 'a' replacing alt. On second thought, maybe I won't make this change... Anyway, ignoring these (unavoidable) complications, the idea is to standardize both the terminology and the code to use strokes "almost everywhere", that is, everywhere except where a Qt-specific or Tk- specific alternative is needed. Summary 1. I'm reasonably sure that driving commands from the description of needed arguments is required to handle difficult special cases with @mode. The extra work is justified by the desire to support vim. 2. Standardizing strokes may help a bit, but nobody should delude themselves into thinking that Leo's key-handling code can ever be simple. Indeed, the complexity arises from the simplicity and generality offered to the user. The code could be radically simplified only at the cost of reducing what Leo can (and should!) do. 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.
