#1269: Leo's key code has been refactored and simplified

[Edward K. Ream]

#1269 has been a great success. Testing continues.

Simplifying Leo's key code was unexpectedly easy. The first step was to eliminate all evil kwargs in the key-handling code. It was then possible to refactor the code. The results were better than I had hoped.

Scripts and plugins can now use k.masterKeyHandler, c.doCommandByName, and c.insertCharFromEvent as resources for handling incoming keystrokes. Scripts and plugins may choose to execute or ignore any commands that might be bound to those keys.

k.masterKeyHandler has been around for decades. Now, it's easy to see what k.masterKeyHandler does. At last, its top level shows all and only the most important code. No mysterious hacks remain. This new transparency means that devs can use various parts of k.masterKeyHandler for their own purposes. I'll give an example below.

k.doCommandByName looks up the function corresponding to the command name and calls that function. That's all. k.simulateCommand has collapsed in complexity. It is now a thin wrapper around k.doCommandByName.

Finally, c.insertCharFromEvent handles an incoming character without executing any command that might be bound to it. k.masterKeyHandler calls c.insertCharFromEvent if there is no binding for the character in the widget having focus.

Here is an example of adapting the code in k.masterKeyHandler for specific purposes. Suppose you want a script that handles abbreviations before calling c.insertCharFromEvent. k.masterKeyHandler shows how. It ends with:

# Handle abbreviations.
if k.abbrevOn and c.abbrevCommands.expandAbbrev(event, event.stroke):
    return
c.insertCharFromEvent(event)

Summary

#1269 has been a great success:

Leo's key-handling code is no longer an embarrassment. Evil kwargs are gone. All functions do just one well-defined thing.

Scripts and plugins can now use k.masterKeyHandler, c.doCommandByName, and c.insertCharFromEvent as resources for handling incoming keystrokes.

The top-level of k.masterKeyHandler now clearly shows the essential steps involved in handling incoming keystrokes. Devs can use parts of this top level code for their own purposes.

Testing will continue for a few more days before I merge the "keys" branch into devel. Please report any problems immediately.

Edward

P.S. As noted in #1269, I have abandoned the #1594, which was the old "phase 2" of the project. Imo, the new code is good enough as it is.

EKR

[Edward K. Ream]

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