Can Leointeg Achieve Near Parity With Leo?

[Thomas Passin]

I've need thinking about leointeg and how I've been using Leo.  This has generated some thought and questions, so I thought I'd air them here.  Felix has done magnificent work with creating leointeg, no doubt about it, and I hope he will post some of his thinking here.

One topic is about scripting.  I write Leo scripts all the time.  Sometimes they are to do a little calculation or programming test.  Sometimes they add commands to Leo's repertoire.  I wrote a script to launch external files, which has become a part of the Leo core distribution.  I think of the scripting capability as being a vital, even essential, capability of Leo.

Leointeg users can't be expected to depend on Leo's scripting.  Who would want to write a Python script in Leo if they have only ever been a VSC/leointeg user?  No, they need the ability to write javascript/typescript scripts in leointeg.  To be really useful, scripts need access to leointeg internals, the equivalent of g and c in Leo.

How does this work in leointeg?  Or if it can't be done as yet, will such scripting become feasible later?

A second area is how to make use of other VSC facilities from within leointeg.  For example, VSC has an extension that provides a markdown view of a document opened in a VSC editing window.  The Leo viewrendered3 plugin can play that same role.  How can leointeg connect with that markdown extension to display leointeg body content in the MD viewer? Or, if we must write our own extension to do it, can we make it access VSC capabilities so as to be able to display the markdown in another pane?

Of course, this is a matter more general than just markdown or ReST rendering.

Along the same lines, it would be very good if we could run a python (or javascript, or some other language) program in leointeg but using the VSC debugging facilities.  If that were feasible, leointeg would gain quite an advantage over Leo, whose debugging capabilities aren't very strong.

Lately I have been using Leo as an application platform, as opposed to being an excellent tool for editing and managing software and other projects.  For example, I have created a browser bookmarks manager.  I use it all the time because I can find things with it in a way that I can't with the browsers' own bookmark managers, and because it gives me way more flexibility in editing, organizing, and annotating bookmarks.  

This software resides in a Leo outline; it opens in its own panel in Leo's log pane. The bookmark data is stored and organized in the tree.  So it's an application, one that replaces an in-browser javascript app I wrote years ago.  It uses Leo for its infrastructure.

I have a few other apps of this nature, that use Leo's infrastructure but don't do traditional Leo tasks.

If something like this could be created within leointeg, it would be very useful indeed.

So these are some thoughts for the possible future course of leointeg.  Perhaps only Felix knows if any of this would be feasible, or would be of interest to him.  Please chime in with any thoughts and reactions!

[Félix]

> I hope he will post some of his thinking here.

You bet i will ! :)

> Who would want to write a Python script in Leo if they have only ever been a VSC/leointeg user? 

Python coders for one! (They are plentiful!)

> No, they need the ability to write javascript/typescript scripts in leointeg. 

Well yeah, I guess many developers (like me) would also like that for sure!

> How does this work in leointeg?  Or if it can't be done as yet, will such scripting become feasible later?

I'm guessing you already know about python scripting in leointeg, which is ran on the leoBridge which can still do anything you would have make it do in regular leo, except the UI interaction with the user. As you stated. 

About scripting in javascript: this is being implemented in leojs. All (almost all) of what you've described is being implemented as 'leojs'. A complete rewrite of Leo, line by line, in typescript, that allows scripting in javascript. With all that such feature implies: access to c, g, p etc. and access to vscode's API.

Leojs is almost done, I'm hoping to have an alpha version out before summer time :)

> VSC has an extension that provides a markdown view of a document opened in a VSC editing window.  The Leo viewrendered3 plugin can play that same role.  How can leointeg connect with that markdown extension to display leointeg body content in the MD viewer? 

I get what you mean, but I'm not sure how i would go about to implement this., On the other hand, as an equivalent, I just use the vscode's markdown view for the whole markdown file that I derived as an external file. which i find useful in itself to be opened beside a body pane to live-preview the generated .md file (via @clean.)  

like so:

> About debugging the code written in leointeg / leojs via vscode's debugger. 

 i guess you mean having the debugger select the appropriate line for breakpoints in body panes? Please give more explicit examples of implementations of features that you think of.  I'm not sure what way leointeg could be integrated more with the vscode's debugger api/panels. Maybe those description will make me see what you mean and i will implement them if i can. (since you already can debug the generated code in leointeg through the vscode debugger api. so i'm not sure what you mean exactly in your description of features/usage. ) 

> Lately I have been using Leo as an application platform,  ( ... ) If something like this could be created within leointeg, it would be very useful indeed.

Leojs will fulfill all those desires. (well, that wounded a bit weird.. hehe ! )

Leojs is almost done, I'm hoping to have an alpha version out before summer time :)

Thanks again, and please do provide more details as to what ways could leointeg be used in vscode's debugger panel/api that you can imagine.

Félix

:)

In darth vader's voice, comparing the death star to the dark side of the force :  "The power of leointeg is insignificant compared to the power of leojs!"