recommend an approach or path to learning more about Leo

[HaveF HaveF]

Hello,

I have mastered the basics of Leo and am using it daily this year. I can use Leo to manage contents, write commands, create buttons, and even develop a small interface on the Log/Find/Tags/Nav panel. However, I'm not satisfied and wish to delve deeper into Leo.

I have an idea to create an importer for a specific file format, but I stopped by my understanding of Leo.
Create an importer is not important and not a high priority for me, It's just one of many ideas that I can't implement because I don't know Leo well enough.

I'm eager to expand my knowledge of Leo. While reading code is a viable learning method, I find the scope of Leo overwhelming. Could you recommend an approach or path to learning more about Leo that is manageable and not too steep?

Thanks!

[Jacob Peck]

"Too deep" is definitely a bit subjective, and will vary by person.

But what I found helpful is to build a few plugins.  Find some pocket of your workflow that you think could be just a little bit better 'if ZZZZ' and write a plugin that does ZZZZ.

Plugins are a good way, imo, to limit your exposure -- you'll likely only be interacting with the parts of Leo's code you really need for your intended functionality.  Unfortunately there's no real way to avoid reading Leo's source code, but you definitely don't have to drink from the firehose to get a better understanding of it.

Jake

--
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/bd6bd906-bfe5-4425-a68b-cad2dd6e4783n%40googlegroups.com.

[HaveF HaveF]

Hi, Jake,

Thanks for your idea. 

I do like learning deeply, but step by step.

I mean, I don't want learning curve 'too steep'

You received this message because you are subscribed to a topic in the Google Groups "leo-editor" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/leo-editor/g0Irx8egu7A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAJ1i%2BSbbdSyVf7ObkLNj%3DGGeGbL9%3D82VGy5fXd%2BS%2B37qrBYW1w%40mail.gmail.com.

--

--
Sincerely,

HaveF

[Thomas Passin]

Leo programming can definitely be a challenge.  It's tempting to say "go look at plugin X", for example, but what's really needed is a way to find out how to do things, how to discover the right existing part of Leo's code base, and how to go about the work effectively.  There isn't anything comprehensive along these lines, and Leo is so big and capable that it can support a great number of very different kinds of scripts an applications.  LeoDocs and the Cheat Sheet help, but only scratch the surface.

In addition, in many cases one has to learn some PyQt as well, and that has its own learning curve.  I tend to learn about using Qt by writing small scripts to some some Qt thing I'm interested in.

I've been slowly working a New User's Guide, but it won't cover the kinds of things you are asking about even when I get it more fully fleshed out.

Since you mentioned writing a interface for the log pane, here's a link to a series of posts I wrote about creating applications that run in a tab: Creating Qt Apps That Run In A Tab

I think that the suggestion of writing plugins is good, but I find it even easier to write experimental code as scripts in a Leo outline.  With a script it's easy to experiment, and you can even write code that changes core Leo behavior.  For example, Leo can optionally show a vertical guide line at the right margin of the body.  I developed that code in a script.  The script monkey-patched core Leo code.  When I got it working right, I then went ahead and incorporated the code (via a pull request) into Leo's code base in PyLeoRef.  Remember, you can use the full power of @others and named sections in a Leo script, and you don't even have to have the script in an external file.

There are various little techniques that make working with Leo's code easier.  Different people use different ones and I don't think there's an extensive compilation anywhere.  I make heavy use of searching with the Nav tab, and marking nodes for easy navigation.  Edward makes effective use of clones and search patterns.

This may not have been all that helpful, but I think that working out ways to find Leo's features and interfacing with them is one of the more important things you can do, and that's going to take a lot of trial and error.  Taking on a limited task as you did with a log pane interface is definitely a good way to start.

[Edward K. Ream]

On Sat, Dec 9, 2023 at 8:02 AM HaveF HaveF <iamap...@gmail.com> wrote:

I'm eager to expand my knowledge of Leo. While reading code is a viable learning method, I find the scope of Leo overwhelming. Could you recommend an approach or path to learning more about Leo that is manageable and not too steep?

Thanks for this excellent question.

Leo is all about outlines, and the point of outlines is to choose the level of detail appropriate for your task.

Imo, LeoPyRef.leo is the only reasonable starting point for study. Forget the documentation. It describes the code's results.

In the remarks below, don't try to memorize anything!  Just read to get a rough picture. Don't overwhelm yourself!

In LeoPyRef.leo, the top-level Code node contains all of Leo's code.

The first child of the Code node is About this file. It's a good idea to read it and its three children.

Next, locate Leo's files. Read the docstrings if you like, but the file names will (after a while) tell you what you need to know.

You already know about c, g, and p. Find the corresponding modules in the Core node:

leoGlobals.py defines g.

leoApp.py defines g.app, the LeoApp class. This class contains global data.

leoNodes.py defines the Position class (p) and VNode class (p.v).

leoCommands.py defines parts of the Commands class (c).

The Commands node contains all files in the leo.commands package.

This package injects methods into c using @cmd and @g.command decorators. There is no need to understand how they work :-)

The Gui Base Classes node defines the base classes for all guis.

The Qt gui node contains files that implement Leo's Qt gui. Beginners need not understand this code.

Summary

The children of the Code node contain all of Leo's sources.

Each of Leo's files is an @file node whose children are the file's classes.

Don't try to remember much. Focus only on the code that is relevant to you.

Next, pick a Leo project that matters to you and find the code that does something similar.

HTH.

Edward

[HaveF HaveF]

Nice.

Thanks for your advice, Edward, Thomas, and Jake!

--

--
Sincerely,

HaveF

[Edward K. Ream]

On Sunday, December 10, 2023 at 7:00:12 AM UTC-6 Edward K. Ream wrote:

> Imo, LeoPyRef.leo is the only reasonable starting point for study. Forget the documentation. It describes the code's results.

But once you read Leo's sources, it's time to dive in!

First, create a new git branch based on devel. This branch will contain your work.

Don't even think about programming without git. It's the essential safety net.

Next, get comfortable with g.trace(g.callers()) and breakpoint, a Python primitive. Run Leo from a console for these.

If you like, add traces or breakpoints to Leo's code to see how Leo works. To see these in action, run a test program in another console.

The hard part is getting started. Expect to put ten units in for every unit out. It's the only way. You'll gain momentum soon enough.

Edward

[Edward K. Ream]

On Sunday, December 10, 2023 at 7:23:53 AM UTC-6 Edward K. Ream wrote:

Next, get comfortable with g.trace(g.callers()) and breakpoint, a Python primitive.

I meant to say, breakpoint().

My myLeoSettings.leo defines the bp;; abbreviation as:

breakpoint()  ###

The ### reminds me to remove the breakpoint later.

EKR

[Thomas Passin]

On Sunday, December 10, 2023 at 8:23:53 AM UTC-5 Edward K. Ream wrote:

To see these in action, run a test program in another console.

This little tip is remarkably useful. Whether you are working on Leo code or your own, each time you want to test a change run a new copy of Leo and keep the original Leo session open.  You can designate a particular outline (often the workbook, the way I work) on the command line so the second Leo session will open faster. 

You don't need to do this for a script that doesn't change code that Leo uses, but otherwise test in a second session.  You will have to close it each time you make a correction, but you will keep your place in the code in the original window, which would probably open more slowly as well.

[Edward K. Ream]

On Sunday, December 10, 2023 at 7:23:53 AM UTC-6 Edward K. Ream wrote:

> Don't even think about programming without git.

Here are some "looking over my shoulder" tips related to workflow:

Leo's git-related commands and scripts

I frequently use Leo's git-diff (gd) and git-diff-pr commands. These commands show the diffs as a Leo outline. They are usually better than corresponding git commands.

LeoPyRef.leo contains two notable Leonine scripts relating to git diff:

script: diff-branches/revs (all files)

script: diff-branches/revs (one file)

Please take a look. The latter script came in handy in the recent emergency concerning leoAtFile.py!

git console scripts

I control git from the console. To save typing, I have defined several git-related shortcuts as scripts:

ga: git add

gb: git branch

gc: git commit

gco: git checkout

gd: git diff

gm: git merge

gmd: git merge devel

gs: git status

These scripts all take arguments. For example, `ga .`

These scripts save a lot of typing!

Summary

Investing in git is part of the art of programming.

As I write this, I see that my recent posts apply to learning any new programming language.

Edward

[Edward K. Ream]

Thanks Thomas. You have described my workflow exactly.

Edward

[HaveF HaveF]

I meant to say, breakpoint().

 It does not work well on my Mac. It constantly output:

QCoreApplication::exec: The event loop is already running

[HaveF HaveF]

Thank you Thomas, your explanation is very, very clear. I get the point. 

[Thomas Passin]

I forgot to say that I run the second Leo session using a theme with a different color scheme from the first one.  That way I don't get mixed up and make a change in or close the wrong window.  You can set a specific theme with the --theme= command line parameter.

[HaveF HaveF]

I forgot to say that I run the second Leo session using a theme with a different color scheme from the first one.  That way I don't get mixed up and make a change in or close the wrong window.  You can set a specific theme with the --theme= command line parameter.

Nice tip! Thanks! 

[Thomas Passin]

On Sunday, December 10, 2023 at 9:08:27 AM UTC-5 Thomas Passin wrote:

On Sunday, December 10, 2023 at 8:23:53 AM UTC-5 Edward K. Ream wrote:

To see these in action, run a test program in another console.

...

You don't need to do this for a script that doesn't change code that Leo uses, but otherwise test in a second session.  You will have to close it each time you make a correction, but you will keep your place in the code in the original window, which would probably open more slowly as well.

Another big benefit of using a second Leo session is if you are working on core Leo code and you make a mistake that prevents Leo from running.  If you only used the one Leo window, you are in trouble because you won't be able to start Leo to fix the mistake.  If the second session fails you can fix up the problem in the still-open first session.

Don't scoff, it's happened to me many times.

[HaveF HaveF]

On Mon, Dec 11, 2023 at 3:06 AM Thomas Passin <tbp1...@gmail.com> wrote:

Another big benefit of using a second Leo session is if you are working on core Leo code and you make a mistake that prevents Leo from running.  If you only used the one Leo window, you are in trouble because you won't be able to start Leo to fix the mistake.  If the second session fails you can fix up the problem in the still-open first session.

Don't scoff, it's happened to me many times.

Thank you for highlighting this little trick that is not difficult, but does improve efficiency.

I found that there are a lot of tricks scattered in the forums. I wondered, would it be better to collect all this content? 

[Edward K. Ream]

On Sun, Dec 10, 2023 at 6:35 PM HaveF HaveF <iamap...@gmail.com> wrote:

> I found that there are a lot of tricks scattered in the forums. I wondered, would it be better to collect all this content?

Leo's info items collect such knowledge. Be sure to check the closed items.

This thread has inspired me to create my own Last Lecture as an info item. Stay turned.

Edward

[HaveF HaveF]

Leo's info items collect such knowledge. Be sure to check the closed items.

Wow! 

 

This thread has inspired me to create my own Last Lecture as an info item. Stay turned.

Looking forward to it.

Btw, your daily workflow is also a great info item as I asked before. You don't need to think too much about what to teach us, just do what you want to do, and I think it must be valuable.

I'm recording some of my daily work to analyze. A few weeks ago, I read an old post about the same thing, "The Coach in the Operating Room". Very inspiring, I hope you guys will enjoy it

[Edward K. Ream]

Btw, your daily workflow is also a great info item as I asked before. You don't need to think too much about what to teach us, just do what you want to do, and I think it must be valuable.

Will do. My Last Lecture will probably say surprisingly little about programming.

Edward

[HaveF HaveF]

 My Last Lecture will probably say surprisingly little about programming.

That's good, we're curious about anything about the father of Leo