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

[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

[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.

[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

[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

[Edward K. Ream]

On Tue, Jun 27, 2023 at 9:48 PM HaveF HaveF <iamap...@gmail.com> wrote:

I don't know the meaning of short url, is it just for easy look?

Yes. The new @data unl-path-prefixes setting resolves relative to absolute paths. As a result, shorter (relative) paths are likely to be more useful than long (absolute) paths.

But this is a preference :-)

Edward