On Tue, Jun 27, 2023 at 9:48 PM HaveF HaveF 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) path
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,
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 v
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, sin
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*
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 anoth
