leoInteg: experiences and suggestions

[Edward K. Ream]

I spent some time yesterday trying to implement Leo's git-diff command in leoInteg.  No success yet. However, this instantly increased my experience with vs code and leoInteg. There is no substitute for making all the newbie mistakes and confronting the resulting mysteries :-)

Having to using "native" vs code to handle leoInteg's sources clearly shows Leo's advantages. With a fully functional leoInteg, I would be able to edit Leo nodes rather than having to navigate flat files.

The following are comments and suggestions arising from recent experiences...

Consider making leoInteg a plugin now

Is this suggestion premature? Would releasing a plugin make debugging more difficult?

For sure, release leoInteg as a plugin would simplify some aspects of the user experience. It might also reveal new hangnails.

Key bindings

Ctrl-` always is bound as in vs-code.

When focus is in the Leo outline, Shift-arrows should move the outline nodes. At present, one must use Alt-Shift-arrows.

Don't open the console by "accident"

Switching between two open .leo files also opens the console area.

Serious bug: the wrong headline may change

I'm not sure how to reproduce this, but it happened several times so I know it's real. It probably happened regardless of whether I used Ctrl-H to edit a headline or whether I used a mouse click to initiate the edit.

Iirc, I was editing ekr.leo, which contains clones. Don't know whether clones are involved.

Serious performance problems

I often navigate through an outline using repeated arrow keys. At present, this is painfully slow. Leo handles this situation much faster. Imo, this performance bug must be solved before releasing leoInteg 1.0.

Fixing this problem may entail a redesign of leoInteg:

The fundamental problem is that at the time an arrow key is pressed leoInteg doesn't know whether the user is about to press another arrow key. Perhaps leoInteg might initiate the switching of nodes immediately, while being prepared to abort/interrupt the node switch if another arrow key arrives before the switch is complete.  This is speculation.

I can think of at least two reasons for the poor performance: slow rendering on the vs code side, and slow communication between vs code and Leo's bridge.

I have no real idea what the solution may be. Perhaps leoInteg may have to implementing Leo's fundamental leoTree.select method in ts.

Summary

The headline bug should be fixed asap. Users will  lose data if they don't notice what has happened.

Please consider releasing leoInteg 0.1 even without the headline bug fix.  Daily updates are fine with me. I don't care if we get to version 0.9.2952 before releasing 1.0 :-)

Please consider doing whatever is necessary to be able to develop leoInteg with leoInteg.leo. Imo, this is much more important than the performance bug. Imo, proper integration will allow us both to ignore Leo sentinels. When this happens, we can use @file instead of @clean.

The performance bug should be fixed before leoInteg 1.0. Otherwise leoInteg will not properly showcase what Leo can do.

Edward

[Edward K. Ream]

On Monday, July 13, 2020 at 4:41:04 AM UTC-5, Edward K. Ream wrote:

> The performance bug should be fixed before leoInteg 1.0.

Good news. leoInteg already works as I would like. If keystrokes come too fast, leoInteg handles them without full redraw.

I'm not sure why I thought there was a performance bug, especially since Félix discussed with me during our zoom meeting.

Edward

[Félix]

AAaahhhhhhhh ! The universe makes sense again! :) 

Well almost... but i wont discuss that on the forums ! ;)

[Edward K. Ream]

On Mon, Jul 13, 2020 at 9:50 AM Félix <felix...@gmail.com> wrote:

AAaahhhhhhhh ! The universe makes sense again! :) 

Well almost... but i wont discuss that on the forums ! ;)

Do you want to talk on zoom?

Edward

[Edward K. Ream]

On Monday, July 13, 2020 at 4:41:04 AM UTC-5, Edward K. Ream wrote:

Serious bug: the wrong headline may change

I'm not sure how to reproduce this, but it happened several times so I know it's real. It probably happened regardless of whether I used Ctrl-H to edit a headline or whether I used a mouse click to initiate the edit.

Hmm. I wonder if I was confused about what node was actually selected. This might have happened if I had left the mouse hovering over a node that wasn't c.p. Otoh, when editing a headline the text area at the top shows the old headline text, so one would think I would have noticed.

I am going to reproduce the supposed bug now...

Edward

[Edward K. Ream]

On Monday, July 13, 2020 at 6:35:32 PM UTC-5, Edward K. Ream wrote:

> Hmm. I wonder if I was confused about what node was actually selected. This might have happened if I had left the mouse hovering over a node that wasn't c.p. Otoh, when editing a headline the text area at the top shows the old headline text, so one would think I would have noticed.

> I am going to [try to] reproduce the supposed bug now...

While switching nodes I got this popup message:

Unable to open 'LEO: BODY': Unable to read file 'leo:/felix.20191126232434.4' (EntryNotFound (FileSystemError)).

And now I see two "body panes".  After deleting the "zombie" pane I re-edited a node whose headline I had changed previously.  Same error.

But now I can't recreate the error again. This is troubling.

Edward

[Félix]

Thanks!
I know where those problems stem from. When I added multi file support, I left unsupported conditions which could not arise with the body file system provider before the multi file support. I will switch priority to those issues.

Félix

[Félix]

Edward.

Regarding 'healines' a (smallish) difference from Leo that might 'trip' someone using leoInteg: When inserting a node, 3 things can happen, 

 1-the user get to type a headline and press enter, 

 2- or press escape to cancel naming and go with 'newHeadline', 

 3- or press CTRL+I again while still supposed to be typing a headline label. 

  (and ctrl+i can be rapidly repeated in both leo and leoInteg with the same effect) 

The difference, in all of those three cases, is that the headline is not visibly inserted in the tree yet while typing its label for the headline in leoInteg, while it is in Leo!

 It sometimes even trips me if I alternate using both leo and leoInteg in a coding session.

So to conclude with that about the possibilities of headline renames off-targets:  That small difference it might have been what happened...

Otherwise, if you remember specifically right-clicking on it, or using ctrl+h for the currently selected node and clearly not inserting new one, then yes, its concerning.

Oh, and yes, The last possibility is that , like you also mentionned, you had mouse hover and actual selection on another node. and ctrl+h thinking it was the other way around.

I'm not too concerned because I never had off target commands, and all commands use the exact same 'system' and mechanism to 'target' nodes.

Body file-system rewrite for stable multi-leo opened documents is more important. dunno why i didn't focus on that after creating all icons and UI for the multi documents panel. (i guess i was too excited with this new cool toy i completely forgot!)

--

Félix

[Félix]

did more tests, i'm narrowing down the zombie body bug(s)- the 'leo browsing mode' and 'multi-file' features combination made the body filesystem provider rewrite mandatory. good news is that I've already had unused functionality in place to handle it properly. I thought I didnt need it (refer to /or /  keep array of gnx's of opened document to give stats to filesystem for any at any time) turns out I do!

i'll do that also in the current days/week. I view it as a priority issue.

--

Félix

[Edward K. Ream]

On Mon, Jul 13, 2020 at 11:00 PM Félix <felix...@gmail.com> wrote:

 

> The difference, [when changing a headline], is that the headline is not visibly inserted in the tree yet while typing its label for the headline in leoInteg, while it is in Leo!

Interesting. This should not matter once there is no need to have two copies of the same .leo file open.

> I'm not too concerned because I never had off target commands, and all commands use the exact same 'system' and mechanism to 'target' nodes.

Good. I haven't seen any problems since my initial report.

Edward

[Edward K. Ream]

On Tue, Jul 14, 2020 at 12:08 AM Félix <felix...@gmail.com> wrote:

did more tests, i'm narrowing down the zombie body bug(s)- the 'leo browsing mode' and 'multi-file' features combination made the body filesystem provider rewrite mandatory. good news is that I've already had unused functionality in place to handle it properly. I thought I didnt need it (refer to /or /  keep array of gnx's of opened document to give stats to filesystem for any at any time)

i'll do that also in the current days/week. I view it as a priority issue.

Thanks.

Edward

[Félix]

omg - Just realized how bad shift+arrows is missing (when: focus on outline) !!! 

I'll make a quick fix for this silly omission before anything

--

Félix

[Edward K. Ream]

On Fri, Jul 17, 2020 at 12:21 AM Félix <felix...@gmail.com> wrote:

omg - Just realized how bad shift+arrows is missing (when: focus on outline) !!! 

I'll make a quick fix for this silly omission before anything

Thanks.

I'm going to attempt, for the second time, adding Leo's git-diff (gd) command to leoInteg. That should keep me busy :-)

My failed first attempt taught me a lot about leoInteg, vs code, and workflow. It was worthwhile.

I'll do this work in a branch based on the ekr branch. I'll be using ekr-leoInteg.leo.

Edward