About ekr-leoInteg.leo

[Edward K. Ream]

Leo's StudyOutlines repo now contains ekr-leoInteg.leo, the Leo outline that I created to study Félix's work. Some notes:

Recursive import script

I created this outline with this script, edited for brevity:

'''Recursively import all python files in a directory and clean the result.'''
@tabwidth -4 # For a better match.

dir_ = r'C:\leo.repo\leointeg\src'
theTypes = ['.ts', ]
g.cls()
c.recursiveImport(
    add_context=True,  # Override setting only if True/False
    add_file_context=False,  # Override setting only if True/False
    dir_=dir_,
    kind = '@clean', # '@auto', '@clean', '@nosent','@file',
    add_path = True,
    recursive = False,
    safe_at_file = False,
    theTypes = theTypes # ['.py', '.ts', '.js','.vue',],
)

As usual with @clean, some manual work at first was needed to properly assign lines to nodes. See below.

Updating after changes

After Félix makes changes, lines can again be assigned to the "wrong" nodes. This doesn't affect the perfect import, but it impedes study.

This is especially true after adding new methods. The @clean algorithm never creates new nodes, so the new methods get put at the end of an existing node.

It's easy to put the new methods in nodes of their own.  Just select the new text, then do parse-body. This creates the new nodes, which you can promote as you like.  I just did this today.

Leo's git diff command

vs codes git lense command is excellent, but Leo's git diff (gd) command is better.  It clearly shows which nodes have changed, which is a much higher view than any pure-text view can possibly be.

Summary

I recommend ekr-leoInteg to anyone wanting to study Félix's work.

Edward

[Edward K. Ream]

On Sunday, July 12, 2020 at 7:11:02 AM UTC-5, Edward K. Ream wrote:

Leo's StudyOutlines repo now contains ekr-leoInteg.leo, the Leo outline that I created to study Félix's work.

I forgot to mention that the leoInteg folder contains leoInteg.leo, which Félix maintains. However, leoInteg.leo contains only the sources for leobridgeserver.py, the python end of the project. ekr-leoInteg.leo contains the typescript sources in leoInteg/src as well as leobridgeserver.py.

Edward

[Félix]

H Edward!

Great ideas and concepts in there! I hope to have time to leonise the whole of the sources when i have less pressing matters and features to attend and realize. Sometimes I regret not having started leoInteg with all sources derived from a leo outline... but I started the project out of frustration of having to alt-tab between the two! 🤣🤣🤣

Those imported outlines will be a super starting point for that! 

I couldn't help but peek at them, and realize that the methods and other objects and objects members have their tsdoc from the following item, instead of their own..

The tsdoc https://github.com/Microsoft/tsdoc standard, as opposed to the python doc string, which is the first thing inside a member or function, is located just _before_ the function/member. 

Maybe this was addressed in a previous message somewhere in this forum or the Leo issues. Sorry if its the case, and please point me to it, if so. :)

--

Félix

p.s. fun-fact/trivia/hint: The most important line in the project, has an end-of-line comment of the single word: "Crux". 

[Edward K. Ream]

On Sun, Jul 12, 2020 at 9:33 PM Félix <felix...@gmail.com> wrote:

Sometimes I regret not having started leoInteg with all sources derived from a leo outline... but I started the project out of frustration of having to alt-tab between the two! 🤣🤣🤣

Perfectly understandable. Full integration will mean never having to consult the "flat" files. When that happens, it will be better to use @file instead of @clean.

Those imported outlines will be a super starting point for that! 

I couldn't help but peek at them, and realize that the methods and other objects and objects members have their tsdoc from the following item, instead of their own..

You might consider starting with ekr-leoInteg.  I moved the trailing comments to the proper node using the move-lines-to-next-node command. This would not be necessary if @file were used.  And no, I have not discussed this before.

Edward