how to get all the content of the body?

[HaveF HaveF]

Hi, Leo user,

Who knows how to get all the contents of the body?
What I want is to replace << xxx >> and @others in the body.

I have created a simple function, but it has problems handling child nodes 
or children of child nodes. I suspect there is a ready-made function, but I 
can't find it anyway, can anyone tell me about it?

Thanks!

Best,
HaveF

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/35b4c6cb-e34e-4d6b-9ade-e47bb57b9fd6n%40googlegroups.com.

Re: Discuss: option for short file names in unls?

[HaveF HaveF]

I don't know the meaning of short url, is it just for easy look?
I use wikiview.py plugin for easy viewing now :D
I think we can just use long url directly, show it shortly (no matter what 
it is). But when press alt and hover the mouse, or edit that line, show the 
long url

On Wednesday, June 28, 2023 at 5:45:30 AM UTC+8 Edward K. Ream wrote:

> On Tuesday, June 27, 2023 at 2:41:21 PM UTC-5 tbp1...@gmail.com wrote:
>
> > I have several immediate reactions:
>
> Thomas, I have no idea what you are afraid of.
>
> > This kind of proposal will create something new that is not a UNL and 
> not a GNX.  
>
> It's a UNL because *g.handleUNL* accepts it. It's a valid URL because 
> *LeoQtLog.linkClicked* and *g.handleUrl* accept it.
>
> And now (in the latest push) Leo calls *urllib.parse.quote* and 
> *urllib.parse.unquote* in better places so there is no need for weird 
> special-case escapes scattered all over the code.
>
> > unl://ekr.leo#g.findUNL, will still not transfer to anyone else's 
> computer or outline.  It's still specific to ekr.leo.
>
> It already works for me. It will soon work for you provided that 
> myLeoSettings.leo contains *@data unl_path_prefixes* setting that gives 
> the full path to ekr.leo on *your* machine. 
>
> Unls like this work for me in test.leo with a hack in *g.parsePathData* 
> that uses a dict hard-coded paths to various .leo files. This hack 
> simulates handling @data unl_path_prefixes. So it won't work for you just 
> yet. But soon.
>
> *Summary*
>
> As you say, cross-file unls are nifty. They now work for both legacy and 
> gnx-based unls.
>
> Little or nothing is going to break. leoSettings.leo now contains these 
> settings:
>
>
> *@string unl-status-kind = legacy@bool full-unl-paths = True*
>
> Leo will work *exactly* as before with these settings.
>
> I know what I am doing. I am putting long hours of work into this project. 
> Everything will soon work as we both want.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0fa34dca-0565-43c0-b4ac-75d3ef1cce8bn%40googlegroups.com.

Heads Up - My Workbook Is Getting Destroyed

[Thomas Passin]

I haven't filed an issue on this yet because I haven't got all the 
conditions nailed down.  But Leo has been replacing my workbook with the 
default CheatSheet ... sometimes.  *Please* make sure you have a backup 
copy until this gets resolved.

I noticed this behavior while I was testing code with the branch 

Leo 6.7.4-devel, ekr-3181-mypy-links branch, build b9a9205ae9

This is the branch with with all the new unl code.  I'm not sure if it can 
also occur on the devel branch.

The problem is that this behavior seems to happen suddenly.  Once it 
starts, every time I launch Leo with this command line, the workbook.leo 
outline gets replaced:

py -m leo.core.runLeo

If I include the name of the outline the outline does not get replaced:

py -m leo.core.runLeo .leo\workbook.leo

When the outline gets replaced, I noticed that the other outlines that were 
opened previously did not get opened.  This made me think that the database 
was getting corrupted.  But I deleted the .leo\db directory and the 
workbook still got deleted.

I think that something the the experimental branch is corrupting some 
string, maybe of the recent files list.  This prevents Leo from finding the 
workbook.  So it creates a new one.  I have observed that changing back to 
the devel branch does not stop this behavior on the first launch, but after 
I run Leo once in devel and then restore the workbook from backup, after 
that Leo behaves normally and does not replace the workbook.  When I switch 
back to the experimental branch, that's when this problem starts happening 
again.

I suggest that if Leo cannot find the workbook when it wants to open it, it 
should notify the user that it can't find it and ask if it should create a 
default workbook.  The user will probably say "no!" since they will know 
that they want to keep the existing one.

Of course, the problem should be fixed, but this would prevent the loss of 
the workbook in case of future bugs as well.  I don't know about you, but I 
have a lot of work in my workbook that I really don't want to lose.

I was saved by Leo's new automatic backup, so I had a workbook.leo.bak file 
when I first realized realized the problem. (Yes, I do back up the .leo 
directory, but not recently enough this time).

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bec70551-834a-46cc-90d6-fa1c4d344b73n%40googlegroups.com.

Re: Discuss: option for short file names in unls?

[Edward K. Ream]

On Tuesday, June 27, 2023 at 2:41:21 PM UTC-5 tbp1...@gmail.com wrote:

> I have several immediate reactions:

Thomas, I have no idea what you are afraid of.

> This kind of proposal will create something new that is not a UNL and not 
a GNX.  

It's a UNL because *g.handleUNL* accepts it. It's a valid URL because 
*LeoQtLog.linkClicked* and *g.handleUrl* accept it.

And now (in the latest push) Leo calls *urllib.parse.quote* and 
*urllib.parse.unquote* in better places so there is no need for weird 
special-case escapes scattered all over the code.

> unl://ekr.leo#g.findUNL, will still not transfer to anyone else's 
computer or outline.  It's still specific to ekr.leo.

It already works for me. It will soon work for you provided that 
myLeoSettings.leo contains *@data unl_path_prefixes* setting that gives the 
full path to ekr.leo on *your* machine. 

Unls like this work for me in test.leo with a hack in *g.parsePathData* 
that uses a dict hard-coded paths to various .leo files. This hack 
simulates handling @data unl_path_prefixes. So it won't work for you just 
yet. But soon.

*Summary*

As you say, cross-file unls are nifty. They now work for both legacy and 
gnx-based unls.

Little or nothing is going to break. leoSettings.leo now contains these 
settings:


*@string unl-status-kind = legacy@bool full-unl-paths = True*

Leo will work *exactly* as before with these settings.

I know what I am doing. I am putting long hours of work into this project. 
Everything will soon work as we both want.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/88f70ccf-6f83-40a8-bf29-0534e0751aa6n%40googlegroups.com.

Re: Discuss: option for short file names in unls?

[Thomas Passin]

I have several immediate reactions:

1. It was not long ago that we had a long discussion about whether to keep 
using functions in @path headlines.  The outcome was no, don't include 
them.  Why should it be different here?

2. Existing code in plugins and application-style scripts will break, since 
it will not understand the new format.  It will be much harder to write 
code to process the new format.

3. I'll try to say this in the clearest way, something I've commented on 
before.  This kind of proposal will create something new that is not a UNL 
and not a GNX.  Don't try to pretend that it is.  Call it a "unlx:", 
perhaps.  They should be manipulated by new methods with new names.  Old 
core code can be changed by search-and-replace operations if needed, but 
the existing functionality should be kept as is.  Imagine if URLs were to 
have functional changes like this after 30 years.  The entire WWW would 
break.

4. I'm certainly a fan of having outlines use relative paths so they can be 
moved.  So I do favor addresses and pointers that can be either relative or 
absolute.  But note that the example above, unl://ekr.leo#g.findUNL, will 
still not transfer to anyone else's computer or outline.  It's still 
specific to ekr.leo.

5. Though we normally discourage using clones across outlines, my 
zettelkasten system uses gnxs to cross-link information.  The only way an 
outline like this can be copied is to clone all the nodes so the gnxs will 
be unchanged.  So I oppose any change that would make this not work.  
Adding a file path to a gnx for the purpose of creating a findable address 
(e.g., a new style unl) would be fine with me, but changing the gnxs 
themselves would not.

6. I'm not quite sure what is being proposed under the labels "short" vs 
"long" paths, but rather than needing a new setting to use them I think 
that the method Leo will use to process them should figure it out either 
way, just like so many figure out whether a path is absolute or relative.  
The current UNL handling code has a set of known places it searches if it 
can't resolve a path, and the same could be done here.  In terms of 
programmatically creating UNLs, say if a script wanted to create unl-like 
addresses for all qualifying nodes in a subtree, there could be a 
well-defined algorithm for shortening an absolute path.  This should be in 
a method of its own, not buried as part of the overall handling method.
On Tuesday, June 27, 2023 at 2:43:01 PM UTC-4 Edward K. Ream wrote:

> On Tuesday, June 27, 2023 at 1:34:40 PM UTC-5 Edward K. Ream wrote:
>
> Yet another new setting, *@bool full-unl-paths = True* (with the 
> legacy-compatible default), would choose between the long and short forms.
>
> ... 
>
> This option must *not* affect what p.get_UNL returns.
>
>
> Hmm. gnx-based unls *will* contain file parts, so this option *should *affect 
> what p.get_UNL returns.
>
> Edward
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/c5abe344-879e-43b1-9aaa-6acda68cf059n%40googlegroups.com.

Re: Discuss: option for short file names in unls?

[Edward K. Ream]

On Tuesday, June 27, 2023 at 1:34:40 PM UTC-5 Edward K. Ream wrote:

Yet another new setting, *@bool full-unl-paths = True* (with the 
legacy-compatible default), would choose between the long and short forms.

... 

This option must *not* affect what p.get_UNL returns.


Hmm. gnx-based unls *will* contain file parts, so this option *should *affect 
what p.get_UNL returns.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0ccf63e5-bbed-42c6-be7f-1d5ba0a7de00n%40googlegroups.com.

Discuss: option for short file names in unls?

[Edward K. Ream]

Legacy unls have always contained a full path name. For example:

unl://C:/Users/Dev/ekr.leo#g.findUNL & helpers

However, the proposed *@data unl_path_prefixes* setting would render 
long/absolute paths unnecessary, so using the following should work: 

unl://ekr.leo#g.findUNL & helpers

Yet another new setting, *@bool full-unl-paths = True* (with the 
legacy-compatible default), would choose between the long and short forms.

This option would affect what gets displayed in the status area and also 
what p.get_legacy_UNL returns. This option must *not* affect what p.get_UNL 
returns.

What do you think?

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/13345084-bf69-4af4-922f-7546be73da22n%40googlegroups.com.

ENB: Unbreakable UNLs: a status report

[Edward K. Ream]

 

This Engineering Notebook post discusses PR #3215 
, especially Thomas's 
valid concerns about compatibility. Despite mistakes, work is going well. 
Our collaboration has been a great success.


Consider this post an update to the PR's requirements, hehe.


*Hot spots*


The PR touches many files, but only the following are of concern:


- *g.findUNL* resolves legacy (path-based) unls (to a position).

- *g.findGNX* resolves new (gnx-based) unls.

- *g.handleUNL* opens other outlines using the *file part* of a legacy unl.

- *LeoQtLog.put* contained an ugly hack, now removed.

- *p.get_UNL* returns the (clickable) unl for p. This is not the same as 
p.gnx!

- *backlink.py* uses complex code found in g.handleUNL.

- The new section *<< About clickable links >>* documents unls.


*Testing*


I have rewritten a unit test, TestGlobals.test_g_findGNX, but this test 
does not cover clicks in unls! I use *leo/test/**test.leo* to test 
clickable links and error messages by hand.



*File parts are broken*


The PR mishandles the file part of legacy unls. I removed too much code in 
g.handleUNL. However, the legacy code was also buggy. It resolved file 
parts using Leo-specific paths!


Imo, g.handleUNL (or a new delegate) needs a new setting, say *@data 
unl_path_prefixes*. g.handleUNL will parse these data to create a 
dictionary. Keys will be outline names (as found in unls); values will be 
the first argument to os.path.join. So this setting will help convert 
outline names to absolute paths.


*Aha!* gnx-oriented unls should be allowed to contain file parts!


g.findUNL and g.findGNX now search for matches in all (open) outlines. This 
search was a failed experiment. I'll remove the code.


*Compatibility*


Two of Thomas's plugins break when p.get_UNL returns a gnx-based unl. We 
can't let that happen :-)


Otoh, I won't create a setting telling what p.get_UNL returns. That's too 
big a "mode switch" in Leo's heart. Such a switch would double Leo's 
testing load.


Most of Leo's core, including most plugins, should work regardless of what 
p.get_UNL returns. In most cases, all that matters is that Leo resolves 
unls to the proper position. Let's call this the *round-trip property* of 
unls. 


I'll also revise the backlink plugin. It contains horrid legacy code from 
g.handleUNL. This code must go.


A new setting, say *@string unl-kind*, will tell what kind of unl appears 
in the status line.


*Summary*


I'll work with Thomas to ensure his plugins survive this PR with minimal 
changes. Most of Leo's core and plugins should continue to work as they are.


See the PR for the complete to-do list. The highlights:


- Make file parts work again.

*- *Allow file parts in gnx-oriented unls.

- *@string unl-kind* will tell what appears in the status line.

- *@data unl_path_prefixes* will contain prefixes to convert relative paths 
(in unls) to absolute paths.


Please continue testing. You can use test.leo to test clickable unls and 
error messages. 


Keep your comments and bug reports coming! There is no rush.


Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/f2f3fda9-2507-409c-bf3d-8cc31ef70b4en%40googlegroups.com.

Re: About PR #3215: unbreakable unls!

[Edward K. Ream]

On Mon, Jun 26, 2023 at 10:44 PM Thomas Passin  wrote:

In the zettelkasten app, using the new p.get_legacy_UNL() doesn't work
> right.  I *think* it's because I had to change the ">" to "%3E" to get QT
> to pass it to my code when I click on these links (these paths appear in an
> anchor element).  So there must be another of the changed methods that
> doesn't quite play right with this.  I'll try to track it down tomorrow.
>

Thanks for this.  It's an important clue.

Edward

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3fbFPxjO6cA3fdqkswpm3C%3DtwGJt66a86Vo8pa%3DnY3CQ%40mail.gmail.com.