LeoInteg progress afterthought

[Félix]

Here I will lay out a couple of basic principles that I now apply when working on this project. I have gathered them in the last year while trying to get Leo and vscode's APIs to behave nicely with each other. (They are NOT applicable on other programming projects that do not consist of bridging two different, unknown APIs.)

By reading this, you will be (more) prepared to contribute to leointeg by being aware of the type of comments and objections I might bring forward.

This is not 'fun' programming with nice algorithms being created, and the like. It's a work of binding "this to that" from an api to the other. There will be plenty of time to do 'fun' programming with it after it's done.

Each time I have endeavored into making leointeg do more than Leo, I regretted it, had to undo my work and redo something simpler that really mimicked what the Leo behavior was, without adding 'features' to it. (Examples: Making any gnx editable simultaneously, opening any node beside other editors without changing selection in Leo, unfolding / collapsing without selecting in Leo, as Leo selects each node it travels to while browsing, and many more...)

At each and every 'value added feature' that seemed like a good idea and that seemed to work, it came back to bite me on the *ss down the road when implementing more thing that, I thought at the time, were unrelated.

After the 3rd or 4th time that my ideas of grandeur simply made the project get delayed by months at a time, I now make sure I implement any general Leo feature into vscode in the most simple, easy, basic way possible that just reflects what Leo does in appearance.

The goal, and reasoning behind this, is more than just a reaction to "I get frustrated & delayed when I have to roll back when I fail to implement an additional 'cool' feature".

While really, In fact it's more of an "Lets get all basic features going in a generic, usable manner, and then we'll add cool features that were not even in Leo, or at least better than some that were in Leo."

Lastly, if a feature is accidentally made better, I leave it at that obviously. For example, in Leo the coloring is applied correctly when selecting a node. (changing coloring triggers by typing while staying in the same node may not apply coloring correctly, but re-selecting a node fixes it.) In vscode, the rules are reapplied at any keypress perfectly, or so it seems, so that's a happy accident that's totally acceptable, and in fact appreciated greatly.

... if that makes any sense.

Félix

[Edward K. Ream]

On Sun, Jun 28, 2020 at 8:49 PM Félix <felix...@gmail.com> wrote:

Here I will lay out a couple of basic principles that I now apply when working on this project. I have gathered them in the last year while trying to get Leo and vscode's APIs to behave nicely with each other. (They are NOT applicable on other programming projects that do not consist of bridging two different, unknown APIs.)

Many thanks for these remarks. They are helpful and insightful.

This is not 'fun' programming with nice algorithms being created, and the like. It's a work of binding "this to that" from an api to the other. There will be plenty of time to do 'fun' programming with it after it's done.

I agree completely. Leo's flexx and console guis are examples of this kind of work. I never got to what I would consider 100% usability, partly because of the limitations of browsers (for flexx) and npyscreen (for the console gui). Nobody knows better than I the immense amount of work required to do a complete gui.

The LSP protocol is another example of the work involved in bridging api's. This page gives a fairly detailed ts example. I thought maybe a server written in python would be simpler. Googling found this page. The code is difficult, even in python.

Each time I have endeavored into making leointeg do more than Leo, I regretted it

Yes, there will be plenty of time for improvements later.

There is a larger design issue, one that has no obvious right answer: what exactly are Leo's essential features in the context of vs-code?

I woke up with this question before reading your post. In particular, what are Leo's essential settings when using vs-code? Clearly, many settings in leoSettings.leo become moot. But which ones? For example, Leo has lots of colorizer settings, but imo it would be more natural to use vs-code's settings for each language.

Eventually, leoInteg might open, say, vscodeSettings.leo instead of leoSettings.leo. One could even imagine specifying existing vs-code settings using vscodeSettings.leo.  But that's for much later, or never. Still, representing settings as an outline is a perfectly reasonable thing to do.

After the 3rd or 4th time that my ideas of grandeur simply made the project get delayed by months at a time, I now make sure I implement any general Leo feature into vscode in the most simple, easy, basic way possible that just reflects what Leo does in appearance.

This is a wise choice. leoInteg is a huge project as it is.

Lastly, if a feature is accidentally made better, I leave it at that obviously. For example, in Leo the coloring is applied correctly when selecting a node. (changing coloring triggers by typing while staying in the same node may not apply coloring correctly, but re-selecting a node fixes it.) In vscode, the rules are reapplied at any keypress perfectly, or so it seems, so that's a happy accident that's totally acceptable, and in fact appreciated greatly.

I'm glad you mentioned this. My present plan for syntax coloring is to create a "leo" LSP server. This will be the "mother of all servers": it will delegate all syntax coloring (except Leonine constructs) to the "real" colorer for the @language in effect at the cursor.

As I said in another post, this will use leoInteg's json description of Leonine constructs, but much more work is required. On every keystroke the "leo" server will have to compute (the possibly cached) value of the language to use, then redispatch the request to the proper LSP. It won't be fun, as the code I mentioned earlier shows.

... if that makes any sense.

It makes perfect sense.

Edward

[Edward K. Ream]

On Sunday, June 28, 2020 at 8:49:39 PM UTC-5, Félix wrote:

This is not 'fun' programming with nice algorithms being created, and the like.

Imo, leoInteg is worth any amount of work :-)

I don't actually have the right to say this, because I'm not doing the work! However, I want to emphasize that imo the leoInteg project is the most important project in Leo's world right now:

1. vs-code looks like the future of programming tools. It will likely have the best set of plugins for the foreseeable future.

2. leoInteg has a great chance of introducing thousands or even millions of people to Leo. No other Leo project can even come close to leoInteg's potential impact.

3. vs-code looks like the best way to bridge to Joe Orr's work. More generally, vs-code looks like the best way to access web technologies.

Edward