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 -- 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/f4de056d-60b4-47ef-8b6f-49271ad96bc0o%40googlegroups.com.
