The prototype now is passing LeoKeyEvents to k.masterKeyHandler. This involved quite a bit of single-stepping using winpdb.
k.masterKeyHandler is now (rightly) complaining because the LeoKeyEvent does not contain a proper stroke. Correctly synthesizing a proper stroke from the curses key code will take considerable work. I don't want to single-step through the code to debug this work. That would be slow and unpleasant. Two tools would reduce the need for single-stepping: 1. Make the present log pane scrollable, and send all g.trace output to it. This page <http://npyscreen.readthedocs.io/widgets-multiline.html> describes various npyscreen multi-line text widgets. If I am not mistaken, the present code acts like a pager. Instead, I want the log pane to scroll so that the last written lines are visible. 2. Create a new tool that uses winpdb's client-server architecture that creates a separate console in which to show the output from g.trace. This must be doable. Given that all of the winpdb sources are available, it should be straightforward. Imo, this project is worth doing on its own. I investigate both approaches today. Each is interesting and each will be valuable in future for maintainers. Developing these tools will be more fun than single stepping :-) It reminds me of something P.J. Plauger said at the ANSI C Standards Committee meeting many years ago. Just because an airplane flies at 30,000 feet doesn't mean it should be built at 30,000 feet :-) 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
