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.
