Leo active file bug and how to get the content of unl

[HaveF HaveF]

Hi, there,

I am delighted to see that the Leo editor is still under active development. The leojs has been a pleasant surprise as well.

After a hiatus of several years, I have returned to using the Leo editor. To this day, I have yet to find any software on the market that rivals the advanced philosophy embodied by Leo.

Initially, I thought I had forgotten how to use the Leo Editor. However, when I found myself in a rush, needing to switch between the Outline and main editor window, I instinctively pressed Ctrl-t. I was rather taken aback to realize that my muscle memory for Leo was still intact!

I sincerely hope that EKR is well.

I'm currently facing a few issues and hope that someone could provide me with some guidance:

1. In version 6.7.3, on MacOS 12, there appears to be an active file bug. I have recorded a video to better illustrate the issue. Unfortunately, even after updating Leo to version 6.7.4-devel, the bug persists. https://www.youtube.com/watch?v=R5L3UShZLsk

2. Is there a simple method to access the content of a specific `unl://` node? I found `core/LeoPyRef.leo#Code-->Core classes-->@file leoGlobals.py-->g.Urls & UNLs`, but it doesn't seem to provide the right function for my needs. With the help of gpt, I can't get the answer. But it is interesting...maybe we need a `getAtNodeFromUNL` function XD

On another note, I've found that pipx is more user-friendly than pip. After installing pipx, I can easily use the command `pipx install leo`. If I need to add something to the Leo environment, I can simply use `pipx inject leo xxx`.

I strongly recommend incorporating pipx into the documentation as an alternative to pip.

Best,

HaveF

[Thomas Passin]

On Sunday, June 25, 2023 at 3:27:38 AM UTC-4 iamap...@gmail.com wrote:

[snip]

2. Is there a simple method to access the content of a specific `unl://` node? I found `core/LeoPyRef.leo#Code-->Core classes-->@file leoGlobals.py-->g.Urls & UNLs`, but it doesn't seem to provide the right function for my needs. With the help of gpt, I can't get the answer. But it is interesting...maybe we need a `getAtNodeFromUNL` function XD

Would you explain more fully what you mean by "access the content of..."?  One way is to CTRL-click on the UNL's string in a body node.  This will navigate you to that location, opening the outline if necessary.  It should also be easy enough to write a new command that navigates to a UNL that is in the clipboard. It just depends on what you mean ...

[Thomas Passin]

On Sunday, June 25, 2023 at 3:27:38 AM UTC-4 iamap...@gmail.com wrote:

[snip]

2. Is there a simple method to access the content of a specific `unl://` node? I found `core/LeoPyRef.leo#Code-->Core classes-->@file leoGlobals.py-->g.Urls & UNLs`, but it doesn't seem to provide the right function for my needs. With the help of gpt, I can't get the answer. But it is interesting...maybe we need a `getAtNodeFromUNL` function XD

That ChatGPT transcript is entertaining.  It's like a student who has not digested its lesson but has to say something in class.  The existing method that's most likely to be useful is actually g.handleUnl().  This will navigate to the given UNL, opening its outline if needed.

[HaveF HaveF]

Would you explain more fully what you mean by "access the content of..."?  One way is to CTRL-click on the UNL's string in a body node.  This will navigate you to that location, opening the outline if necessary.  It should also be easy enough to write a new command that navigates to a UNL that is in the clipboard. It just depends on what you mean ...

Hi, Thomas, 

Thanks for your reply. 

I want to get the content of UNL by script, like `p.b` to get the body content in the current node.

--

--
Sincerely,

HaveF

[Thomas Passin]

Do you mean you want a method or function to return the text of the body of the node addressed by the UNL? In general, the UNL could point to another outline.  Will you be looking only in the current outline, or any outline?  And if the latter, do you care if that other outline gets opened during execution of the function?

[Edward K. Ream]

On Sun, Jun 25, 2023 at 7:22 AM Thomas Passin <tbp1...@gmail.com> wrote:

On Sunday, June 25, 2023 at 7:59:09 AM UTC-4 iamap...@gmail.com wrote:

Would you explain more fully what you mean by "access the content of..."?  One way is to CTRL-click on the UNL's string in a body node.  This will navigate you to that location, opening the outline if necessary.  It should also be easy enough to write a new command that navigates to a UNL that is in the clipboard. It just depends on what you mean ...

Hi, Thomas, 

Thanks for your reply. 

I want to get the content of UNL by script, like `p.b` to get the body content in the current node.

 

Do you mean you want a method or function to return the text of the body of the node addressed by the UNL? In general, the UNL could point to another outline. 

Not after PR #3215 :-) I'll be discussing this PR soon.

Edward

[HaveF HaveF]

Do you mean you want a method or function to return the text of the body of the node addressed by the UNL? In general, the UNL could point to another outline.  Will you be looking only in the current outline, or any outline?  And if the latter, do you care if that other outline gets opened during execution of the function?

For now, my UNL points to a position of the current outline. Could we have a quick way to get it?

Looking forward to hearing  PR #3215. it seems a huge PR

--
Sincerely,

HaveF

[Thomas Passin]

"Remove support for cross-file UNLs" -  WTF??? This will break some of my scripts.  How are we going to navigate to other outlines by UNL?  Wasn't that half of the point of having UNLs in the first place?

This looks like a situation where we should be adding a new API method, not changing how the old one works.

[Thomas Passin]

On Sunday, June 25, 2023 at 8:43:25 AM UTC-4 iamap...@gmail.com wrote:

For now, my UNL points to a position of the current outline. Could we have a quick way to get it?

Assuming that these commands will continue to work after the PR:

c0, p0 = c, c.p

c2 = g.handleUnl(unl, c)
content = c2.p.b  # <---- here is the content of the UNL's body
c0.selectPosition(p)

[Thomas Passin]

Oops, typo!  The last line should read

 

c0.selectPosition(p0)

[HaveF HaveF]

Thanks Thomas, I'll try it later

Another thought: is it a good idea to take UNL as a system level schema?

I can record somewhere like markdown `[something](unl://xxxxxxx)` or even pass parameter to that schema if the unl is a script...  `unl://xxxxx?para1=leo`

--
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/_TqPXKhD-rs/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/246ebac0-0439-4592-91bd-9f40bebd3e23n%40googlegroups.com.

--

--
Sincerely,

HaveF

[Thomas Passin]

Markdown won't know what to do with a UNL, so you can't expect navigation to work in the rendered page.  Also, remember that if an outline's organization gets changed - i.e., you move a node - its UNL won't be correct any more.  So you only want to use UNLs like that when you have high confidence the outline will be stable.  (Few of my outlines are that stable).

[HaveF HaveF]

c0, p0 = c, c.p

c2 = g.handleUnl(unl, c)
content = c2.p.b  # <---- here is the content of the UNL's body
c0.selectPosition(p)

Oops, typo!  The last line should read

 

c0.selectPosition(p0)

Hi, Thomas,

It works, thank you!

It's a useful snippet, we should write it down. But where should we save it? Do you know the right place?

https://github.com/leo-editor/snippets seems like a good place, but it doesn't update for a long time.

--

--
Sincerely,

HaveF

[Thomas Passin]

On Sunday, June 25, 2023 at 10:20:28 AM UTC-4 iamap...@gmail.com wrote:

c0, p0 = c, c.p

c2 = g.handleUnl(unl, c)
content = c2.p.b  # <---- here is the content of the UNL's body
c0.selectPosition(p)

Oops, typo!  The last line should read

 

c0.selectPosition(p0)

Hi, Thomas,

It works, thank you!

Great!  And if you want to do the same for a UNL in another outline, you can add these two lines (at least until that PR gets merged; I don't know about after that):

# Add this after the "content ="  line.

if c2 is not c0:

    g.app.selectLeoWindow(c0)

 

It's a useful snippet, we should write it down. But where should we save it? Do you know the right place?

https://github.com/leo-editor/snippets seems like a good place, but it doesn't update for a long time.

It needs a check to handle the case c2 is None, which would happen if Leo can't find the UNL.

Probably a good place is leo-editor-contrib.  Though it can be hard to find things in there.  @Edward has been accepting pull requests there.

 

[HaveF HaveF]

Probably a good place is leo-editor-contrib.  

Interesting resources! Thanks, and have a nice day :D 

--

--
Sincerely,

HaveF

[Edward K. Ream]

On Sun, Jun 25, 2023 at 7:51 AM Thomas Passin <tbp1...@gmail.com> wrote:

"Remove support for cross-file UNLs" -  WTF??? This will break some of my scripts.  How are we going to navigate to other outlines by UNL?  Wasn't that half of the point of having UNLs in the first place?

This conversation is likely out of date:

1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true.

2. The PR continues to support all legacy unls. As before, g.findUNL simply ignores the "file part", that is everything before the '#'.

Edward

[Edward K. Ream]

On Sun, Jun 25, 2023 at 8:05 AM Thomas Passin <tbp1...@gmail.com> wrote:

> Assuming that these commands will continue to work after the PR:

c0, p0 = c, c.p

c2 = g.handleUnl(unl, c)

Oops!  In the PR g.handleUNL returns None. I'll restore the legacy operation immediately.

Edward

[Edward K. Ream]

On Mon, Jun 26, 2023 at 12:32 PM Edward K. Ream <edre...@gmail.com> wrote:

> Oops!  In the PR g.handleUNL returns None. I'll restore the legacy operation immediately.

Done. g.handleUNL returns a commander or None, exactly as in devel.

Edward

[Edward K. Ream]

On Sun, Jun 25, 2023 at 10:22 AM Thomas Passin <tbp1...@gmail.com> wrote:

> Great!  And if you want to do the same for a UNL in another outline, you can add these two lines (at least until that PR gets merged; I don't know about after that):

# Add this after the "content ="  line.

if c2 is not c0:

    g.app.selectLeoWindow(c0)

Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears in both g.findUNL and g.findGNX. So these calls have already been done when g.handleUnl returns.

Edward

[Thomas Passin]

On Monday, June 26, 2023 at 1:29:24 PM UTC-4 Edward K. Ream wrote:

On Sun, Jun 25, 2023 at 7:51 AM Thomas Passin <tbp1...@gmail.com> wrote:

"Remove support for cross-file UNLs" -  WTF??? This will break some of my scripts.  How are we going to navigate to other outlines by UNL?  Wasn't that half of the point of having UNLs in the first place?

This conversation is likely out of date:

1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true.

Yes it has.  Here's the docstring from the (unreplaced) g.findUNL:

  
    Find and move to the unl given by the unlList in the commander c.
   Return the found position, or None.

[Thomas Passin]

That's not the point. This bit of code returns the focus to the original node even if the findUNL() call, for a UNL pointing into another outline, had  changed the focus to that other outline.  The idea is to retrieve the body of the node addressed by the unl without changing the focus.

[Edward K. Ream]

On Mon, Jun 26, 2023 at 12:56 PM Thomas Passin <tbp1...@gmail.com> wrote:

1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true.

Yes it has.  Here's the docstring from the (unreplaced) g.findUNL:

  
    Find and move to the unl given by the unlList in the commander c.
   Return the found position, or None.

The unlList is a list of headlines. Even if the top headline is an @file node, there is no way for the legacy g.findUNL code to open another commander. In other words, you are misunderstanding the docstring.

The legacy g.findUNL does not work the way you think it does. The legacy g.handleUnl function couldopen other outlines, but only in limited places. I removed that code because it was too Leo-specific.

Edward

[Edward K. Ream]

On Mon, Jun 26, 2023 at 12:57 PM Thomas Passin <tbp1...@gmail.com> wrote:

Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears in both g.findUNL and g.findGNX. So these calls have already been done when g.handleUnl returns.

That's not the point. This bit of code returns the focus to the original node even if the findUNL() call, for a UNL pointing into another outline, had  changed the focus to that other outline.  The idea is to retrieve the body of the node addressed by the unl without changing the focus.

And my point was the PR will break as little as possible.

Edward