Re: About PR #3215: unbreakable unls!

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

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 2:26:36 PM UTC-4 Edward K. Ream wrote: On Mon, Jun 26, 2023 at 12:50 PM Thomas Passin wrote: 2. Both the bookmark manager and the zettelkasten apps partially work but not completely. I will look at using these new "legacy" methods next. Let me know if I can

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 1:50:28 PM UTC-5 tbp1...@gmail.com wrote: > Furthermore, having the path visible in the status bar could be really useful. Let's not argue about preferences. I've just added this checklist item to the PR: Add a setting that determines whether the status area will

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 2:01 PM Thomas Passin wrote: Something close to seven plugins use unls, including mod-http and > quickMove. They should all be checked to see if they will still work. Good idea. I've added this item to the PRs list. Edward -- You received this message because you

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 1:50 PM Thomas Passin wrote: Yes, since the UNL contained the path to the outline, Leo could open a > non-open outline and navigate to the right node. I always thought that was > a wonderful, even almost miraculous, capability. We shouldn't lose it. > I've just added

Re: About PR #3215: unbreakable unls!

Something close to seven plugins use unls, including mod-http and quickMove. They should all be checked to see if they will still work (I don't know which of them still work apart from unl changes). -- You received this message because you are subscribed to the Google Groups "leo-editor"

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 2:26:36 PM UTC-4 Edward K. Ream wrote: On Mon, Jun 26, 2023 at 12:50 PM Thomas Passin wrote: g.findGNX searches all *open* windows. The legacy version of g.handleUnl contained Leo-specific code which I deleted. Afterwards, the code called g.openWithFileName to

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 12:50 PM Thomas Passin wrote: 1. CTRL-clicking on an old-style unl pointing into the same outline > navigates to the right node; for a unl pointing into a different outline it > does not navigate to the right place or even the right outline. > Thanks for testing. We'll

Re: About PR #3215: unbreakable unls!

After checking out the branch for this PR: 1. CTRL-clicking on an old-style unl pointing into the same outline navigates to the right node; for a unl pointing into a different outline it does not navigate to the right place or even the right outline. 2. Both the bookmark manager and the

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 10:02:40 AM UTC-5 Edward K. Ream wrote: > I'll add p.get_legacy_UNL and p.get_short_legacy_UNL. > I'll add expanded searching to g.findUNL, just as in g.findGNX. Both done. *Notes* 1. *Warning*: Plugins that call g.findUNL directly must *not *assume that the

Re: About PR #3215: unbreakable unls!

On Mon, Jun 26, 2023 at 9:21 AM Thomas Passin wrote: The bookmark manager needs to 1) flatten the paths of nested nodes (to > provide labels like "software/python/frameworks") and 2) make each step of > those flattened labels clickable so that a user can navigate to their > node. Gnxs can't

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 7:34:57 AM UTC-4 Edward K. Ream wrote: On Sun, Jun 25, 2023 at 10:44 PM Thomas Passin wrote: Actually, bookmarks and zettelkasten should work *better* than before, provided: - they use the *new* p.get_UNL() and - they work with both legacy and new unls, which they

Re: About PR #3215: unbreakable unls!

On Monday, June 26, 2023 at 6:34:57 AM UTC-5 Edward K. Ream wrote: > I'm going to restore g.findUNL() and hook it back into g.handleUnl(). Done, and fairly cleanly too in g.handleUnl(). Please test the ekr-3181-mypy-links branch and report any problems. test.leo now contains working clickable

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 10:44 PM Thomas Passin wrote: > However, I feel strongly that p.get_GNX() should return the position's actual gnx string, which is what the name says it does. p.gnx is p's gnx. That hasn't changed. p.get_GNX() is something completely different. The name is not as

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 10:44 PM Thomas Passin wrote: > > I have just completed taking the currently-existing unl handling functions > p.get_UNL(), g.findUNL(), and g.handleUnl() from the core - the ones > scheduled to go to the attic or be changed - and turned them into > stand-alone functions

Re: About PR #3215: unbreakable unls!

On Sunday, June 25, 2023 at 10:36:32 PM UTC-4 Edward K. Ream wrote: On Sun, Jun 25, 2023 at 4:48 PM Thomas Passin wrote: So now my bookmarks manager will not work, something I use every day and depend on. I suppose I will have to pull out code from the attic and put it into my own module.

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 4:48 PM Thomas Passin wrote: I'm unclear as to whether the gnx string for a given node - that is, p.gnx > - will now be in a different format. p.gnx can never ever change. But p.get_GNX() now returns f"unl:gnx:{self.gnx}". Yes, this is confusing, but it shouldn't

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 4:48 PM Thomas Passin wrote: > So now my bookmarks manager will not work, something I use every day and > depend on. I suppose I will have to pull out code from the attic and put > it into my own module. Or recreate the pathlike part of the functionality, > anyway.

Re: About PR #3215: unbreakable unls!

So now my bookmarks manager will not work, something I use every day and depend on. I suppose I will have to pull out code from the attic and put it into my own module. Or recreate the pathlike part of the functionality, anyway. I'm unclear as to whether the gnx string for a given node -

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 1:44 PM Robert-Felix wrote: > Thanks for this simplification! supporting Leo's unl links is on my todo > list for leojs (and leointeg!) > You're welcome. I'm glad you like the new scheme. I think you'll like the simpler code. Edward -- You received this message

Re: About PR #3215: unbreakable unls!

On Sun, Jun 25, 2023 at 11:49 AM Thomas Passin wrote: > I would rather have created a new gnx:// type and left existing unls alone. I understand your desire for compatibility, but the old url/gnx code was unbearably complicated. I have spent the last week wrestling with the issues. I don't

Re: About PR #3215: unbreakable unls!

Thanks for this simplification! supporting Leo's unl links is on my todo list for leojs (and leointeg!) Félix On Sun, Jun 25, 2023 at 2:38 PM jkn wrote: > Yes, I was a bit surprised this wasn't your approach as well. Looking > forward to the results regardless... > > > On Sunday, June 25, 2023

Re: About PR #3215: unbreakable unls!

Yes, I was a bit surprised this wasn't your approach as well. Looking forward to the results regardless... On Sunday, June 25, 2023 at 5:49:36 PM UTC+1 tbp1...@gmail.com wrote: > I would rather have created a new gnx:// type and left existing unls > alone. Will existing UNL syntax and

Re: About PR #3215: unbreakable unls!

I would rather have created a new gnx:// type and left existing unls alone. Will existing UNL syntax and methods still work? On Sunday, June 25, 2023 at 12:00:26 PM UTC-4 Edward K. Ream wrote: > PR #3215 changes > many files in complex

About PR #3215: unbreakable unls!

PR #3215 changes many files in complex ways. See detailed comments in the first comment of the PR. This PR started as a fix for a minor bug , but work expanded in unexpected directions.