Unifying leoPy.leo and leoPlugins.leo is a big win

44 views
Skip to first unread message

Edward K. Ream

unread,
Oct 16, 2020, 11:19:01 AM10/16/20
to leo-editor
Now that I have done so, I regret not doing it years ago. I had been taking consul of nameless fears. In fact, every aspect of Leo's development has been simplified:

- Clones naturally span both plugins and Leo's core. The clone-find and git-diff commands work much better.
- I now use a unified "Recent Code" organizer, and that has had happy effects in organizing my to-do lists and lists of completed items.

Similarly, the open-leo-py-ref-leo command makes it significantly easier to keep LeoPyRef.leo in sync with my personal leoPy.leo files. It may sound like a small matter, but it isn't.

Summary

So-called "little" improvements can sometimes be very important. Not everything is an earthquake like the clone-find commands :-)

Edward

vitalije

unread,
Oct 17, 2020, 8:29:58 AM10/17/20
to leo-editor
Similarly, the open-leo-py-ref-leo command makes it significantly easier to keep LeoPyRef.leo in sync with my personal leoPy.leo files. It may sound like a small matter, but it isn't.

I think you should really try using public/private outline scheme. Just to remind you of this rather hidden Leo feature.

If an outline has a top level node with the headline `---begin-private-area---`, then this node is separating the public part of the outline (before this node) and the private part of the outline (after this node). The first line of this node should have a path to the public (shared) Leo document.

Now when you execute c.fileCommands.save_ref() command, the public part is saved in the shared Leo document. In my private Leo documents I always have a node with headline `@button n-save @key=Ctrl-s` and the body line always contains at least these two lines:

c.save()
c
.fileCommands.save_ref()

That way my public or reference Leo files never get out of sync.

When I pull changes from the others, I have to remember to execute `read-ref-file` which updates public part of the outline from the reference file.

Vitalije

Edward K. Ream

unread,
Oct 17, 2020, 4:22:44 PM10/17/20
to leo-editor
On Sat, Oct 17, 2020 at 7:30 AM vitalije <vita...@gmail.com> wrote:

I think you should really try using public/private outline scheme.

Thanks for the reminder. I'm not sure I always want ctrl-s to save to both outlines. Instead, I'll create a new command that only calls c.fileCommands.save_ref().

Edward

vitalije

unread,
Oct 18, 2020, 7:49:25 AM10/18/20
to leo-editor
I use it in my LeoPy.leo and it was never an issue. If all my work is done in the private zone, git never showed LeoPyRef.leo changed.
Vitalije

Edward K. Ream

unread,
Oct 18, 2020, 8:46:53 AM10/18/20
to leo-editor
On Saturday, October 17, 2020 at 3:22:44 PM UTC-5, Edward K. Ream wrote:

> I'll create a new command that only calls c.fileCommands.save_ref().

Per #1716, LeoPyRef.leo now contains @button write-leoPyRef, a specialized rewrite of fc.save_ref():

- It can only be run from leoPy.leo, and always writes to LeoPyRef.leo.
- It writes only a given list of nodes,  ['Startup', 'Notes', 'Code'], thereby eliminating the need for a sentinel node.

I think this specialization makes sense. In any case, I am happily using it.

Please let's not argue about this. It's my preference.

Edward
Reply all
Reply to author
Forward
0 new messages