Broken Add/Delete Body Editor

[Phil]

I am seeing that multiple body editors is broken. To see this, do the following:

• open an empty Leo file
• create two nodes A and B with body content A and B respectively
  
• create a new body editor
• select node A
• add a body editor
• select node B
• click in the node A body editor - observe the node B body editor now shows A
• click in the node B body editor
• delete the body editor
• observe that nodes A and B both have content A
  

I have the following:

Leo 6.8.1
Python 3.12.4, PyQt version 6.7.2
linux

[Thomas Passin]

I can confirm this behavior and it is a serious bug.  One workaround is to select Node B and do an Undo action (CTRL-z).  Your typing into Node B will be there.

If you mostly want to read node A wile editing Node B, you can use the freewin plugin.  This will open a basic editor that will always be locked to the node you started it in. You can edit in it and the changes will be reflected in its host node, but it does not have all the editing actions and commands of a full body editor.  On the positive side, you cannot type into the wrong node by mistake, as is so easy to do with Add-Editor.

[Jacob Peck]

Please submit a bug report if you have not: https://github.com/leo-editor/leo-editor/issues

Any loss of data is a critical bug.

Thanks,

Jake

--
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 leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/302adb61-9fc2-42dd-9f0c-6600f1a72e10n%40googlegroups.com.

[Thomas Passin]

I have submitted Issue #4046

[Edward K. Ream]

On Friday, August 23, 2024 at 11:01:36 AM UTC-5 Phil wrote:

I am seeing that multiple body editors is broken.

I see this too. This issue (#4046) means that Leo 6.8.2 will go out the door sooner than expected.

It seems likely that this issue has lurked for months, perhaps even years.

The code that supports multiple body editors is too complex for me to understand.

Why does Leo need multiple body editors? Why doesn't the stickynotes plugin suffice?

Edward

[Thomas Passin]

It didn't do it several years ago.  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.

[Edward K. Ream]

On Sat, Aug 24, 2024 at 7:00 PM Thomas Passin <tbp1...@gmail.com> 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 <edre...@gmail.com>
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

[Thomas Passin]

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.

[Edward K. Ream]

On Sun, Aug 25, 2024 at 6:21 AM Thomas Passin <tbp1...@gmail.com> wrote:

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?

Anything is possible.

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.

Neither do I.

PR #4047 is ready for review.  As you can see, the PR changes little, but deletes a lot of horrible code.

I'll add more detail to the PR's checklist later today.

Edward

[Thomas Passin]

We should wait a little to see if anyone responds, shouldn't we? We know at least one person was interested enough to try using Add-Editor.  Maybe there are others who haven't been updating Leo all along.

[Edward K. Ream]

On Sun, Aug 25, 2024 at 7:49 AM Thomas Passin <tbp1...@gmail.com> wrote:

We should wait a little to see if anyone responds, shouldn't we? We know at least one person was interested enough to try using Add-Editor.  Maybe there are others who haven't been updating Leo all along.

I agree. There's no rush. The workaround for the present problems is just not to use add-editor.

Otoh, the present code appears beyond saving.

Edward

[Thomas Passin]

" Leo has been solid all these years because my supreme design goal has been to minimize unwanted dependencies between unrelated modules."

I don't think the body editor construction quite meets this goal.  It seems to be intertwined with creating the top dynamic window. Ideally, it should be possible to create a body editor and just plug it into whatever container widget is wanted.  Currently it gets created with and inserted into a bunch of different frames and ivars.

It's trivial to change the bodyStackedWidget, where the editor hangs out, into a QTabWidget. If a body editor could be created as a widget on its own, that widget could simply be inserted into a new tab in the tabbed widget. The DW pointer to the editor could be reassigned to this new editor. IOW, there would be a single ivar that would be the only reference to the editor.  But currently there doesn't seem to be a way to do this without a lot of complication.

Actually, changing the stacked widget to a tabbed widget could have a benefits aside from the possibility of added editors. Plugins like VR/VR3 and RPCalc could be inserted as new tabs.  Removing them would be dead easy. I've already got a branch with this change as a proof of principle - see attached image.  This way, Leo's body frame would work like many other editors, e.g. VSCode, in that you could add any number of tabs, each with its own kind of widget.

[Edward K. Ream]

On Sun, Aug 25, 2024 at 9:48 AM Thomas Passin <tbp1...@gmail.com> wrote:

" Leo has been solid all these years because my supreme design goal has been to minimize unwanted dependencies between unrelated modules."

I don't think the body editor construction quite meets this goal. 

The DynamicWindow class creates all aspects of Leo's window. This class could be improved, but none of the changes would carry significant consequences outside the dw class, much less other modules.

In other words, the "supreme design goal" does not prevent ugly or incomplete code.

Edward

[Phil]

As I am "at least one person" using (or had been using)  this, here's more about my usage of Add-Editor:

• I have been using Leo for many years, and have been updating my Leo every 6-12 months
• I use the extra body editor to show example code in one node and code being developed in another node, using the example as a guide.
• I also have experienced confusion over which pane is the "example" and which is "working". But I get over it and move on.

I would not be upset if this feature went away. My alternative is to open the example code in different text editor and just arrange the Leo and Editor windows side-by-side. This also eliminates the confusion over which window is which.

[Jacob Peck]

Hi Phil,

The stickynotes.py or freewin plugins may offer the feature set you need for this workflow.

Jake

--

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 leo-editor+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/4521ea06-fae5-40c5-a988-fd0f5821120fn%40googlegroups.com.

[Thomas Passin]

Yours is just the use case I had in mind when I developed the Freewin plugin. You do have to adjust the sizes of both the FW window and Leo's window to avoid overlap but I don't find that much of a nuisance.  You could even have a freewin view of a node in a different outline than the one you are working in. A FW window always displays the host node it was opened to, even if you select another node later.  You can do basic editing in the FW window, and the edits will get put into its host node.

[Edward K. Ream]

On Tue, Aug 27, 2024 at 5:55 PM Phil <phil....@gmail.com> wrote:

As I am "at least one person" using (or had been using)  this, here's more about my usage of Add-Editor:

...

I would not be upset if this feature went away. My alternative is to open the example code in different text editor and just arrange the Leo and Editor windows side-by-side. This also eliminates the confusion over which window is which.

Thanks for checking in on this topic.

Edward