It looks like the colorizer might be getting the wrong position - the position of the original editor rather than the newly focused position. Might there be a p.copy() involved here?
I don't understand the code very well either, but one of the complicated things is that all the signaling and ivars get moved over to whichever editor widget gets the focus. I don't see why that was necessary since if the editing widget were inactivated it shouldn't receive any signals anyway. Maybe it would have been better to only use one editing widget and when the focus gets changed to the other editor panel, the first one gets replaced by a screen shot and the single editing widget actually gets inserted into the second panel. Unless there is going to be some improvement in the user interface that will prevent confusion about which node is being edited by which editor, I don't have any interest in trying to sort this thing out. On Sunday, August 25, 2024 at 2:57:39 AM UTC-4 Edward K. Ream wrote: > > > On Sat, Aug 24, 2024 at 7:00 PM Thomas Passin <[email protected]> wrote: > >> It didn't do it [have the bug] several years ago. > > > Leo 6.7.8 was the last official version that did not suffer this bug. Leo > 6.8.0 and 6.8.1 do have the bug. > > I did a git bisect: > > a37e1eb2af74c8d53d325325d563a30f6dc100b3 is the first bad commit > commit a37e1eb2af74c8d53d325325d563a30f6dc100b3 > Author: Edward K. Ream <[email protected]> > Date: Tue Apr 23 04:44:59 2024 -0500 > > Fix #3809 by adding jedit.Colorize(!!) > > leo/commands/commanderOutlineCommands.py | 5 ++++- > leo/core/leoColorizer.py | 11 +++++++++++ > leo/core/leoFrame.py | 3 ++- > 3 files changed, 17 insertions(+), 2 deletions(-) > > I wouldn't bet my life that this is the culprit, but let's assume for a > moment that it is. This commit adds the following: > > def colorize(self, p: Position) -> None: > """jedit.Colorize: fully recolor p.b.""" > if not p: > return > self.updateSyntaxColorer(p) > # Similar to code in jedit.recolor. > self.init_all_state(p.v) > self.init() > # Force QSyntaxHighlighter to do a full recolor. > self.highlighter.rehighlight() > > Could this *new* code be the culprit? Yes, it looks like it is! The bug > disappears when I disable jedit.colorize!! > > Folks, it looks like the multiple-body code has reached the point of being > impossible to understand. > > Say at the time I added the freewin plugin. I didn't like the added editor >> because it was too easy to get confused about which editor instance was >> seeing which node. I kept making mistakes, typing into the wrong node. >> That influenced my design for freewin, where a FW window always stays >> locked to the same node. >> > > The stickynotes plugin is similarly easy to use. > > *Summary* > > Leo has been solid all these years because my supreme design goal has been > to minimize unwanted dependencies between unrelated modules. But it looks > like the innocent-looking rev a37e1e broke Leo. Imo, it's time to > eliminate everything associated with the add-editor command. > > Your comments, please. > > 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/83346bf1-8434-4ab5-9310-9a9dc7cefa3fn%40googlegroups.com.
