#1269 <https://github.com/leo-editor/leo-editor/issues/1269> suggests a radical simplification of Leo's key handling code. Python's Hypothesis <https://hypothesis.readthedocs.io/en/latest/>unit testing framework gives me more confidence that the project could be completed without introducing an unending number of subtle bugs. For this reason, I have reopened #1269.
There are myriad paths through the existing key-handling code. The new code would be radically different. We need some way of testing all paths through both the old and new code. Hypothesis provides a way of *thinking* about the testing problem. We generate "random" tests from a universe of tests whose union covers all cases. In practice, testing will find erroneous edge cases without testing all test cases. "Random" testing would not be required. For sure, we will also need explicit tests. Hypothesis can handle such cases, and will likely suggest where random testing is, in fact, necessary. *The general plan* This section will be pre-writing for an expanded first comment of #1269. The new code will compute a tree of *binding dictionaries* *during startup*. Afterward, Leo will handle incoming keys by "traversing" this tree using *binding selectors*. The selectors will include the keystrokes themselves, states, modes, and widgets. Leo will perform dictionary lookups based on selectors, in some not-yet-defined order. The result of each lookup will be a *flat key handling method*. Each flat key handling method will do something simple with the incoming key. In other words, these methods will replace all (or almost all) Leo's existing key handling code, including k.masterKeyHandler and k.masterCommand, *and all their helpers*. The result should be a significant speedup in key handling speed. *Summary* A complete testing plan is essential for #1269. The problem is to ensure that the new code is exactly equivalent to the old. Hypothesis helps assure us that a complete testing plan is possible. A tree of binding dictionaries, created at startup time, should save significant time processing keystrokes. Up to five lookups, based on binding selectors, will yield a specific flat key handling method. The testing challenge is to prove that the new flat key handling methods do the same as the existing code. This testing constraint will likely drive significant parts of the design. This is still a risky project. I make no promises. 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/56ab62cd-d0b6-46b4-b9f7-54bccb3410fe%40googlegroups.com.
