On Jan 8, 4:26 pm, "Edward K. Ream" <[email protected]> wrote:
> > The plan will be to define method in qtQui.py that will override > > (monkeypatch) Leo's commands such a next-line, next-line-extend- > > selection, etc. The new methods will simply generate a key event. > > This is almost certainly a bad idea: it mixes the implementation of > commands with bindings. The situation is complex, and something > simple like this has almost no chance of "just working". After bouncing my ideas with Rebecca at the dinner table tonight, I now have a plan that has an excellent chance of working. The main idea is to think about Leo's commands, not gui keystrokes. In essence, the key handling code in qtGui.py should know as little as possible about Leo's commands: it should be concerned *only* with translating Qt key events into so-called "strokes": the Tk names for the key events. At present, there are some bugs in this logic and these bugs can and should be fixed without changing any part of Leo's core. As I said, the proper place to fix problems with cursor movements is at the command level, that is, the code that implements commands such as next-line, previous-line, next-line-extend-selection, etc. After talking with Rebecca, and consulting the documentation for QTextEdit, a simple plan emerges. The code for next-line will ask the gui whether it has a method called nextLineHelper. If it does, the next- line code will call the helper. The helper will move the cursor **without** generating any key event! In fact, the helper will just call QTextEdit.moveCursor. Very simple. Here is an important detail: nextLineHelper is only *part* of the next- line code. The next-line command does more than just move the cursor; it also updates the status line. However, nextLineHelper relieves the next-line code of a *lot* of work. In particular, we can assume that QTextEdit not only handles long wrapped lines correctly. Thus, the next-line code doesn't have to remember column information: it only has to *retrieve* the column information after the cursor has, in fact, moved. In short, I am fairly confident that this scheme will fix the following two bugs: - 421957 When body_pane_wraps is set to true, Previous-Line and Next- Line do not work as expected. - 489917 Cursor placement defect The bug today involving ctrl-tab is separate: it relates to hacks in the eventFilter method (and its helpers) in qtGui.py. My guess is that some of the complications in eventFilter are mostly accidents: accretions that have built up over time. However, today's work suggests two possible improvements to eventFilter: 1. eventFilter should (modulo details to minor and horrible to relate) send *all* key events to k.masterKeyHandler. That is, Leo's Qt gui code should know as little as possible about key bindings. 2. Today's report of ctrl-tab illustrates the need for a new command, something called insert-tab-or-indent-region. At present, this *function* is handled (via a truly tortuous route) in the updateTab helper of the leoEditCommands.selfInsertCommand. The point is that Leo has *no right* to create a hidden binding of tab to the code in updateTab. Instead, the tab key should be handled explicitly. This will allow vim bindings (or any other bindings) to handle the tab key more flexibly. I suspect the lessons of point 2 above can be generalized a bit to apply to other unbound keys. However, Leo must continue to handle unbound keys properly, no matter how many steps it takes. In particular, there are too many unicode keys to handle separately in eventFilter! In short, more work is needed, but a lot of false starts have lead to a workable plan. Edward P.S. It's vital that as much code as possible remain unchanged, particularly any code that interfaces with the *Tk* code. In fact, there are three or four or five separate parts of code: 1. The binding code that translates user settings into key dictionaries. This must not change, and need not change. 2. The gui code that translates incoming Qt key events into strokes. It may be possible to simplify this a bit now that we know that *all* strokes should be passed to k.masterKeyHandler. (Full disclosure: there are quirks in Qt event handling that make this noble goal very hard to achieve.) 3. k.masterKeyHandler. This has recently been refactored, but it's actual task, translating strokes into command to call, will not change. In fact, today's work indicates that no new refactoring is likely to be needed. 4. The command handlers called by k.masterKeyHandler via k.masterCommand. These will not change at all, except to call gui helpers for commands that move the cursor. 5. The move-cursor helpers in the Qt gui. These haven't been written yet--today's invention was the realization that a) they are needed and b) they can call QTextEdit.moveCursor to get the job done rather than mucking about with generating arrow keys(!) So that's it for now. This is really complex code, and it's vital that it not be changed without careful thought. I believe the new scheme will change the minimum amount of code. Even better, it may decrease the interactions between eventFilter and k.masterKeyHandler. EKR
-- 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.
