On Fri, Mar 23, 2012 at 5:04 PM, Edward K. Ream <edream...@gmail.com> wrote: > On Mar 23, 12:27 pm, "Edward K. Ream" <edream...@gmail.com> wrote: >> On Fri, Mar 23, 2012 at 9:34 AM, Kent Tenney <kten...@gmail.com> wrote: > >> > <alt-x> add-editor is a requirement for my workmethod, seeing >> > the code and the test I'm writing side by side ... > > This is turning into a project.
I feared that, having a vague recollection that it had been investigated and determined a wormhole. I'd been hoping I'd either learn to live with it, or it would go away. > > I can recreate the problem as follows: > > 1. Create the second editor. > 2. Select a node whose body text won't fit entirely in the body pane > (so it must scroll vertically). > 3. Ctrl-End to put cursor at end of text. > 4. Click back and forth between the two body panes. The scroll bars > in the large text will move each time you click the large text. > > **Important**: the unwanted scrolling does *not* happen if you switch > between body editors with cycle-editor-focus. OK,that's the ticket. I'll be better served by configuring and learning keyboard switching. Since no one else has mentioned this, consider it a non-issue, you have more important things to worry about, (cough .. event hooking ..cough) ;-> I'll go the keyboard/command route. Thanks, Kent > > This bug may be hard to fix, because of *I* think is a nasty Qt bug. > Here are my comments at the start of getYScrollPosition: > > # **Important**: There is a Qt bug here: the scrollbar position > # is valid only if cursor is visible. Otherwise the *reported* > # scrollbar position will be such that the cursor *is* visible. > > Iirc, I discovered this bug while tracing the scrollbar position > reported by Qt. I wouldn't bet my life that I am correct about this, > but I'm pretty sure I am. > > In fact, the "offending" code is part of a FocusIn event handler in > the body pane. This kind of event is the worst place to do anything, > because we are (almost by definition) in the middle of a context > switch. That is, the *click itself* changes focus, an now Leo has got > to make sense of what is happen. This includes switching nodes! > > You would think that doing nothing would be perfectly reasonable, as > far as the YScroll bars are concerned, but I'm not sure it is easy, or > even possible, to do nothing ;-) I certainly would *like* to do > nothing, but that involves distinguishing FocusIn events that are the > result of a mouse click (the bug at hand) and FocusIn events that > "just happen" as the result of the cycle-editor-focus command. > > Oh yes, there is another level of complexity. When there is only one > body editor, it is mandatory that the scrollbars (or at least insert > point) are preserved. This is done (mainly) by > v.restoreCursorAndScroll, using v.scrollBarSpot. But when there are > multiple body editors, *each* editor w must maintain its own > position. It's all pretty hairy. > > In short, I'll continue to investigate my options, but I am not going > to change the code drastically at this point. That's asking for big > trouble in either b2 or final. It's not worth the risk. I have a few > more ideas for smallish changes, but if they don't work out the only > reasonable course would seem to be to ask you to bind a key to cycle- > editor-focus. > > Edward > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to leo-editor@googlegroups.com. > To unsubscribe from this group, send email to > leo-editor+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
