Fix For Ctrl-Click On UNL Not Opening Outline

[Thomas Passin]

Ctrl-clicking on a UNL string in a node is supposed to navigate to that location, even if it's in another outline.  That outline should open if it's not already.  But after the recent changes to the UNL design, the functionality only works within the same outline.  It won't open an outline and navigate to the target node.

A fix is in the works, but Edward and Felix don't have a lot of extra cycles right now to review and approve the PR.  So here is a monkey-patch that restores the navigation capability in advance of merging the PR.  This is basically the same code as is in the PR, packaged as a little outline that can do the monkey-patching.  The code changes g.openUNLFile().

To use, open the outline, select its top-level node, and run its script (with CTRL-b).  The patch will need to be applied again each time you start Leo.

[lewis]

This feature works for me. I have a node with body text:

unl://n:/leo/abc.leo#unl_workbook.leo

Ctrl-click the node headline and file abc.leo opens in a new Tab, with cursor at the specified node.

[lewis]

Ctrl-click on UNL is not broken for me :)

[Thomas Passin]

What version or changeset are you running?  It's been broken for me in devel for a while, and also in 6.7.5.  I get UNLs from nodes, and they look like this:

unl:gnx://LeoPyRef.leo#ekr.20230630132340.1  (New style)

unl://workbook.leo#get unl body ("Legacy" style)

Neither form works for me with a CTRL-click for a file outside the current outline, because -

The new version UNLs do not include the full path to a file, whereas your example does.  Without the full path, the navigation method has to try a series of heuristics to work out the path, and that's what the current method doesn't get right. I get the UNLs to test using p.get_UNL() or p.get_legacy_UNL().  If your example UNL string came from an older version of Leo, well, that's not what you would get with current versions.

[lewis]

Thomas, Ctrl-click on UNL does not open another file if I have setting:

@string unl-status-kind = gnx

[lewis]

I set myLeoSettings file to:

@string unl-status-kind = legacy

I then created a new leo file and created a new node: Test UNLs for Thomas - legacy

You are correct the new version UNLs don't have the full path to the file:

unl://Test_UNLs.leo#Test UNLs for Thomas - legacy

Ctrl-click on a node with that new version UNL does not open the file. Nor does it move to file if already open

Leo Log Window
Leo 6.7.6-devel, devel branch, build ec97534c2d
2023-12-09 16:30:04 -0600
Python 3.12.0, PyQt version 6.6.1
Windows 10 AMD64 (build 10.0.19045) SP0

[Thomas Passin]

On Saturday, December 9, 2023 at 11:57:09 PM UTC-5 lewis wrote:

I set myLeoSettings file to:

@string unl-status-kind = legacy

I then created a new leo file and created a new node: Test UNLs for Thomas - legacy

You are correct the new version UNLs don't have the full path to the file:

unl://Test_UNLs.leo#Test UNLs for Thomas - legacy

Ctrl-click on a node with that new version UNL does not open the file. Nor does it move to file if already open

Exactly.  My patch fixes the problems in so far as it can given that the UNLs don't include the absolute path any more. The heuristic it uses is

    Look for locations in the following places in order:
        1. The currently selected outline
        2. All open outlines
        3. Files specified in an @data setting named 'unl-path-prefixes'
        4. Certain well-known files like PyLeoRef.leo
        5. The outlines listed in the Recent Files menu.

 

#3 is a new setting that Edward introduced when he made the recent changes to the UNL machinery.  I think (or maybe just hope) that #5 will catch most cases of interest, but it's not a perfect solution.

[lewis]

See #3706 which concerns headline focus.

I will try out your patch.

[jkn]

Hello there (eg. Thomas, Edward)

    did this patch, or something like it, ever get added to Leo, do you know?

I encountered a situation today where I had a link of the form

unl:gnx://myfilename.leo#jkn.20240604101758.1

(and an entry in @data unl-path-prefixes to point to the location of myfilename.leo)

Ctrl-click successfully navigates to the location if myfilename.leo is already open, but not otherwise.

I am not clear which PR (mentioned above) is supposed to contain this...

Thanks, J^n

[Thomas Passin]

My memory is blank about the status...

[Thomas Passin]

I have verified that (without my patch) if a new-style UNL is edited to include the full path, then the outline will get opened with a <CTRL-Click>. I don't know if this was intended or an accidental outcome of some legacy code.

Example:

Does not open the outline:

unl:gnx://recreation_notes.leo#TomP.20200621125058.1

Does open the outline:

unl:gnx://c:/tom/recreation/recreation_notes.leo#TomP.20200621125058.1

[jkn]

Thanks for trying this, Thomas

FWIW I am running under Linux and the equivalent of your second example does not work for me (so neither work).

My entries in @data unl-path-prefixes use the ${ENV_VARIABLE} convention as a 'helper' for use across different machines; I re-wrote these to use explicit pathnames but this made no difference.

Nothing in the log pane either.

    J^n

[Thomas Passin]

I can't try this on Linux myself because the current Virtualbox version is broken on my Windows machine. Every keystroke causes multiple keys to be entered, so it's impossible to log in to the VM.  It is probably related to a recent Windows update.  And earlier versions of VB don't work because Oracle didn't sign a module correctly and recently Windows has become more strict about accepting such programs.

[Edward K. Ream]

On Thu, Jul 17, 2025 at 9:07 AM jkn <jkn...@nicorp.co.uk> wrote:

I had a link of the form

unl:gnx://myfilename.leo#jkn.20240604101758.1

(and an entry in @data unl-path-prefixes to point to the location of myfilename.leo)

Ctrl-click successfully navigates to the location if myfilename.leo is already open, but not otherwise.

Everything works for me as expected.  The example in LeoDocs.leo is a bit misleading. The body of @data unl-path-prefixes says:

# lines have the form:
# x.leo: <absolute path to x.leo>

# test.leo:    c:/Repos/leo-editor/leo/test
# LeoDocs.leo: c:/Repos/leo-editor/leo/doc

But the example shows that the lines should be paths to the directory containing your .leo file. Does that help?

Edward

[jkn]

No, I already only have the directories. I must have had to play with this part previously(and successfully),

since I have my own explanatory comment in myLeoSettings.leo:

# map short filenames to full paths -
# may depend on the platform...

#y.leo: <full path to the directory containing y.leo>
#z.leo: <full path to the directory containing z.leo>

# $(ENVIRONMENT_VARIABLE} seems to work here ;-)

Note the comment about ${ENVIRONMENT_VARIABLE} - my entries use this for cross-platform working.

However (as mentioned above) I tried re-writing the path without an environment variable, and still nothing.

I am a bit surprised there is nothing in the log. FWIW I experimented with 'mangling' the filename in the unl:gnx link, and still got no error message

 I am running:

Leo Log Window
Leo 6.8.5-devel, devel branch, build dc00194614
2025-06-22 06:06:45 -0500
Python 3.12.3, PyQt version 6.9.1
linux

[jkn]

An update:

1) to partially confirm Thomas' earlier observation: I can edit a new-style UNL to include the full path, and this it works.

Note that the form has to be slightly different under Linux (three forward slashes ... I lose track of the 'scheme' etc. me4aning of the fields here)

unl:gnx:///home/jkn/Seafile/at_files/@leo/jknprojects.leo#jkn.20250729113758.1     # will open file even if not already open

2) I am trying to confirm this, since it seems to be different on different machines; but on one, currently, if I edit the shortcut to *not* use environment variables, it works:

# myLeoSettings.leo

@data unl-path-prefixes

    jknprojects.leo: ${SEAFILE}/at-files/@leo            # does not work, but used to. SEAFILE=/home/jkn/Seafile
    jknprojects.leo: /home/jkn/Seafile/at_files/@leo    # seems to work on at least one machine; I think it does not work on one machine, I am checking

FWIW I am next to certain that the use of '@' in my directory path is not the issue, I have played with this...

    J^n