On Monday, May 25, 2020 at 2:14:02 PM UTC-5, Edward K. Ream wrote: The first post avoided all details, on purpose. Here, I'd like to discuss a few of those details.
*c.insertCharFromEvent* It's still difficult to explain exactly what c.insertCharFromEvent does. Operationally, it does all key-related processing if there *isn't* a command bound to the incoming key. In other words, k.masterKeyHandler calls c.insertCharFromEvent if a) no special cases apply and b) there is no binding for the key in the widget with focus. What actually happens depends on a *lot* of picky details. When the body pane has focus, the code will insert "printable" characters. These complications are intrinsic. Now, however, a single method handles them all. *New default bindings for <tab> and <shift-tab>* The old code had complex, confusing code for handling "plain" characters. That code has disappeared. To make this work, I changed the default bindings of <tab> and <shift-tab>. See the node: "@shortcuts Text operations" in the tree: "@keys EKR bindings". Also, the indent-region command now simply insert the tab if no text is selected. I am hoping that this change doesn't cause confusion. However, there is no way I'm going back to the old code. *Summary* c.insertCharFromEvent is a huge step forward for Leo and its devs, despite being a bit difficult to explain. Leo now handles <tab> and <shift-tab> in subtly different ways. I apologize for any inconvenience this may cause. Imo, the new code is well worth any initial pain. 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/7e0d01e5-fe3f-400b-9835-ac482b05cd97%40googlegroups.com.
