Improved recursive import in devel. Please update scripts

35 views
Skip to first unread message

Edward K. Ream

unread,
Jun 14, 2023, 9:00:08 AM6/14/23
to leo-editor
PR #3363 improves the outlines created by scripts that call c.recursiveImport.

Please update scripts calling c.recursiveImport. The signature has changed.

Improvements and changes

c.recursiveImport generates an outline containing only relative paths in @file and @path nodes.

Leo will import these nodes correctly only if the .leo file resides in the parent directory of the path specified by the "dir_" argument to c.recursive import. Imo, this convention is the only way of eliminating absolute paths.

Please change all scripts that call c.recursiveImport

The signature of c.recursiveImport has changed. Please revise your scripts accordingly.

The signature had to change because c.recursiveImport works differently.

LeoPyRef.leo now contains a revised "Recursive import script" node that illustrates how to call c.recursiveImport.

Summary

Please revise all scripts that call c.recursiveImport.

c.recursiveImport generates an outline containing only relative paths in @file and @path nodes.

These nodes will work correctly only if the .leo file resides in the parent of the directory given by "dir_" kwarg.

Edward

Edward K. Ream

unread,
Jun 14, 2023, 9:06:35 AM6/14/23
to leo-editor
On Wednesday, June 14, 2023 at 8:00:08 AM UTC-5 Edward K. Ream wrote:
PR #3363 improves the outlines created by scripts that call c.recursiveImport.

One more thing: leo-editor-contrib contains an improved mypy.leo that illustrates the new import scheme. This .leo file should work correctly provided it resides in the parent of the (inner) mypy directory. In other words, the .leo file should work regardless of where the mypy repo is.

Please let me know if you have any questions.

Edward

Edward K. Ream

unread,
Jun 14, 2023, 11:06:01 AM6/14/23
to leo-e...@googlegroups.com
On Wed, Jun 14, 2023 at 8:06 AM Edward K. Ream <edre...@gmail.com> wrote:
On Wednesday, June 14, 2023 at 8:00:08 AM UTC-5 Edward K. Ream wrote:
PR #3363 improves the outlines created by scripts that call c.recursiveImport.

One more thing: leo-editor-contrib contains an improved mypy.leo that illustrates the new import scheme.

And one more thing. Imo it would be best to replace the @path statements in headlines with @path statements in body text: @path statements are context sensitive. That is, they "accumulate". But this means that cloning and moving an @<file> node will change its effective path.

The alternative would be to put the full path (relative to the .leo file) in every @<file> node. This seems too verbose.

I'll create a new PR soon and update mypy.leo accordingly.

Edward

Thomas Passin

unread,
Jun 14, 2023, 11:14:41 AM6/14/23
to leo-editor
On Wednesday, June 14, 2023 at 11:06:01 AM UTC-4 Edward K. Ream wrote:
On Wed, Jun 14, 2023 at 8:06 AM Edward K. Ream <edre...@gmail.com> wrote:
On Wednesday, June 14, 2023 at 8:00:08 AM UTC-5 Edward K. Ream wrote:
PR #3363 improves the outlines created by scripts that call c.recursiveImport.

One more thing: leo-editor-contrib contains an improved mypy.leo that illustrates the new import scheme.

And one more thing. Imo it would be best to replace the @path statements in headlines with @path statements in body text: @path statements are context sensitive. That is, they "accumulate". But this means that cloning and moving an @<file> node will change its effective path.

Yes, pluses and minuses.  With an @path node in the headline, it's instantly clear where all the external child files are located.  If the @path directive were in the body, this wouldn't be so.   But the point about clones is an issue too.  Another matter is how much code is out there that looks for @path in the headline.  I don't know, but we should probably assume there there is some user code that's not part of the Leo source tree.

Jacob Peck

unread,
Jun 14, 2023, 1:08:26 PM6/14/23
to leo-e...@googlegroups.com
I absolutely depend on @path nodes.  Please do not break existing @path-in-headline behavior.

Jake

On Jun 14, 2023, at 11:14 AM, Thomas Passin <tbp1...@gmail.com> wrote:


--
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 leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/95f2683b-d419-4319-bc14-556b89483e27n%40googlegroups.com.

Edward K. Ream

unread,
Jun 14, 2023, 2:05:40 PM6/14/23
to leo-e...@googlegroups.com
On Wed, Jun 14, 2023 at 12:08 PM Jacob Peck <gates...@gmail.com> wrote:

I absolutely depend on @path nodes.  Please do not break existing @path-in-headline behavior.

Perhaps I wasn't clear. Leo will continue to support @path in both headlines and body text.

The design question: where should the new recursive import logic generate @path. Either way should work initially. Putting @path in bodies makes it possible to move clones anywhere.

For me, the answer is clear: put @path in body text.

Edward

Edward K. Ream

unread,
Jun 14, 2023, 5:17:22 PM6/14/23
to leo-editor
On Wednesday, June 14, 2023 at 10:06:01 AM UTC-5 Edward K. Ream wrote:
Imo it would be best to replace the @path statements in headlines with @path statements in body text: @path statements are context sensitive. That is, they "accumulate". But this means that cloning and moving an @<file> node will change its effective path.

Done in devel via PR #3379. The new code handles mypy.leo well.

Please let me know if you would like other changes.

Edward
Reply all
Reply to author
Forward
0 new messages