Design of leojs

[edreamleo]

This issue continues Leo issue #1774. This is the proper place for this discussion.

Félix: leojs...would be most useful to test things on the [vs-code/js] side, without communicating to python / bridge etc., in order to sometimes get some help from vscode's team when trying to have them install and run the extension to test things, and show live-examples of what an (non-literate) outliner can do, without the need for them to also get leo setup. And I would ultimately merge the project into leoInteg. It could also be a starting point for someone who wants to re-do leo in js / rust/webassembly"

EKR: Preliminary design

Hurray! leojs doesn't have to do any of the following.

• Gui stuff, including key handling and themes!
• Standard text-editing commands, including text-oriented undo/redo.
• Abbreviations that expand to text only.
• Code completion.
• Settings, including leoConfig.py, leoSettings.py, and myLeoSettings.leo. vs-code should present Leo's settings organized as an outline. Happily, many of Leo's present settings are not needed in vs-code.
• @test and @suite. leojs should have unit tests. These unit tests should based on standard js testing frameworks, not on leoTest.py (or even leoTest2.py)
• leoBridge.py. leojs might use Leo's bridge, but leojs need not re-implement the bridge.

The kernel of leojs

• A transliteration of Leo's DOM: positions, vnodes, iterators.
• A transliteration of Leo-specific commands, commands not found in other editors.
  • Leo's essential commands must be done first:
    • outline-oriented find,
    • undo/redo
  • Leo's signature commands probably should be done next:
    • clone-find,
    • git-diff and git-diff-pr
    • execute-script (composing scripts from outlines).

Later improvements

The following Leonine features could be postponed until after all essential features are in place:

• A transliteration of the @clean update algorithm. We might be happy using @file or even @nosent for a long time.
• Abbreviations that expand to outlines.
• Leonine scripting: access to c, g and p. Félix: leojs might even have access to the vs-code base!
• Leo's importers.
• Leo-specific plugins.

[boltex]

Other elements that are no longer required to be implemented in the making of leojs, but from the leoInteg point of view:

• Async promise-resolve systems for from-to calls to a bridge communicating with an external process.
• Stack of front end command UI operations to be executed first it - first out, along with back-end stack of bridge commands to be executed on the python side in the same manner.
• Classes that also communicate with calls trough the leo bridge to get objects that collect data about states from Leo (current file dirty, undo permissible, etc...)
• Other objects that managed calls to bridge to get info to populate and refresh the 'opened leo documents' panel and the 'at-buttons' panel

... and more! ;)

[edreamleo]

@boltex Do you mean that the things on the list do have to be done or don't have to be done?

[boltex]

They don't have to be done ;)

Those were needed in leoInteg for the communication with the external leo process, while in leojs, everything is in the same 'process' so none of that is needed to prevent race conditions or de-synchronisation of the internal states.

[edreamleo]

@boltex That's jolly! I'm motivated!