Re: The big PR did remove some gui-related code
On Saturday, July 8, 2023 at 8:10:10 AM UTC-5 Edward K. Ream wrote: On Friday, July 7, 2023 at 7:14:56 PM UTC-5 Edward K. Ream wrote: I now see that the *full_match* helper function (internal to g.findUNL) *did* contain gui code. Imo removing that code was correct, but there is a chance that doing so created problems. FYI: both the convert_unl_list and the full_match helpers will go away when g.findUNL no longer supports old-style unl lists. Oops. The full_match helper function resolves legacy unls. It must remain :-) 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/57cb1910-8289-4e12-8a0a-adffc0451167n%40googlegroups.com.
Re: Aha: no need for a new paste command
The discussion got me to examine the various commands' docstrings via F11. *paste-as-template *was new to me, and might have been handy from time to time. The word "template" doesn't convey anything useful to me about what the command does, but I don't have an alternate to suggest at this moment. The command name *paste-retaining-clones* is a little misleading to me because it leaves a question about what happens to non-cloned nodes in the copied subtree (they keep their gnxs too). The menu item label (*Paste Node As Clone* doesn't quite match up with the command's name, at least to me. I better write some clarifying text about these commands in the new user guide I'm slowly working on, I suppose. On Saturday, July 8, 2023 at 8:50:14 AM UTC-4 Edward K. Ream wrote: > On Sat, Jul 8, 2023 at 6:53 AM Thomas Passin wrote: > >> No, I haven't tried it. I'm not even sure I would want to. >> > > I've asked several times, why not? > > Think about how the Windows file explorer works. If you copy a file and >> paste it, it gives the pasted file a name that includes "copy" if there is >> another file with that name in the same directory. >> > > It's an interesting analogy but misleading. A Leo node is more like a > directory than a file. Subnodes matter in this discussion. > > > The question is whether pastes should retain *all* gnxs or none of them. > > > Yes, Leo could copy a tree depending on whether clashes exist. But it's > our intention that matters, not gnx clashes. That was the Aha. > > > Leo's paste-node and paste-retaining-clones commands support either > intention. That should be enough. > > > *Summary* > > > It's easy to reject the proposal. It's unlikely to work as expected. Leo's > existing commands suffice. > > > 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/84412da0-d1e8-4c5d-8752-8a34f293a4bfn%40googlegroups.com.
Re: The big PR did remove some gui-related code
On Friday, July 7, 2023 at 7:14:56 PM UTC-5 Edward K. Ream wrote: I now see that the *full_match* helper function (internal to g.findUNL) *did* contain gui code. Imo removing that code was correct, but there is a chance that doing so created problems. FYI: both the convert_unl_list and the full_match helpers will go away when g.findUNL no longer supports old-style unl lists. It's not clear whether any code or plugins now use such lists. Removing support for old-style unl lists is scheduled for Leo 6.7.5. It's way too late for such a change now. 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/6d9dda9d-e026-43dd-a951-65df936f8cb1n%40googlegroups.com.
Re: Discuss: remove support (later) for old unls in g.findUnl?
On Sat, Jul 8, 2023 at 7:45 AM Thomas Passin wrote: These apps worked a week ago. I had already adapted them for the big PR > and checked that they work. Part of that was handling an escape that > hadn't needed to be handled previously (%3E for ">"). But here's another > that doesn't have strange escaped characters and doesn't work either: > 'unl://tabbed_bookmarks_manager.leo:#@bookmark-collection > (starter set)-->Python-->Python IAQ Infrequently Answered Questions'. > > These unls are constructed on the fly when the user makes a query. I > suppose it won't be too hard to make this work again. I don't want to put > in the work unless the code is going to be stable. So far I've been > chasing a moving target. > The PR is now frozen, pending comments from you. The tweaks PR changes only g.findAnyUnl and g. openUNLFile. Please let me know if you would like a change in either function. I won't change the PR's code in any way except unless I hear from you. 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/CAMF8tS0bGuL-TtHS%2BZHgaHyRjQT0GHmt4WcNLYSP5PCrZ9zg1Q%40mail.gmail.com.
Re: Aha: no need for a new paste command
On Sat, Jul 8, 2023 at 6:53 AM Thomas Passin wrote: > No, I haven't tried it. I'm not even sure I would want to. > I've asked several times, why not? Think about how the Windows file explorer works. If you copy a file and > paste it, it gives the pasted file a name that includes "copy" if there is > another file with that name in the same directory. > It's an interesting analogy but misleading. A Leo node is more like a directory than a file. Subnodes matter in this discussion. The question is whether pastes should retain *all* gnxs or none of them. Yes, Leo could copy a tree depending on whether clashes exist. But it's our intention that matters, not gnx clashes. That was the Aha. Leo's paste-node and paste-retaining-clones commands support either intention. That should be enough. *Summary* It's easy to reject the proposal. It's unlikely to work as expected. Leo's existing commands suffice. 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/CAMF8tS2g%2B6szSM3sP281KGX_7_Xq87TcVs-P2jgcVMEyNNSDCQ%40mail.gmail.com.
Re: Discuss: remove support (later) for old unls in g.findUnl?
On Saturday, July 8, 2023 at 8:28:09 AM UTC-4 Edward K. Ream wrote: On Sat, Jul 8, 2023 at 6:47 AM Thomas Passin wrote: Using the ekr-tweak-unls branch breaks both the bookmarks and zettel tabbed apps. I will look into what isn't working, but in the zettel browser, I see it's looking for and can't find expressions like 'unl://#tom.20220910123825.1', which is not a legacy unl. This is not proper new gnx-based unl, which must start with 'unl:gnx:' 'unl:gnx://#tom.20220910123825.1' It's unlikely that Leo generated this unl. In the case of the bookmarks manager, it can't find expressions like 'unl://tabbed_bookmarks_manager.leo:#@bookmark-collection (starter set)-->Python-->5 Python GUI Frameworks to Create Desktop, Web, and Even Mobile\xa0Apps. %7C Towards Data Science'. Escapes may be the culprit here. I don't see how Leo can be responsible for non-standard unls that various plugins generate. Edward These apps worked a week ago. I had already adapted them for the big PR and checked that they work. Part of that was handling an escape that hadn't needed to be handled previously (%3E for ">"). But here's another that doesn't have strange escaped characters and doesn't work either: 'unl://tabbed_bookmarks_manager.leo:#@bookmark-collection (starter set)-->Python-->Python IAQ Infrequently Answered Questions'. These unls are constructed on the fly when the user makes a query. I suppose it won't be too hard to make this work again. I don't want to put in the work unless the code is going to be stable. So far I've been chasing a moving target. -- 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/45564d32-080a-429e-9fe2-4099d00c17b2n%40googlegroups.com.
Re: Discuss: remove support (later) for old unls in g.findUnl?
On Sat, Jul 8, 2023 at 6:47 AM Thomas Passin wrote: > Using the ekr-tweak-unls branch breaks both the bookmarks and zettel > tabbed apps. I will look into what isn't working, but in the zettel > browser, I see it's looking for and can't find expressions like > 'unl://#tom.20220910123825.1', which is not a legacy unl. This is not proper new gnx-based unl, which must start with 'unl:gnx:' 'unl:gnx://#tom.20220910123825.1' It's unlikely that Leo generated this unl. > In the case of the bookmarks manager, it can't find expressions like > 'unl://tabbed_bookmarks_manager.leo:#@bookmark-collection > (starter set)-->Python-->5 Python GUI Frameworks to Create Desktop, Web, > and Even Mobile\xa0Apps. %7C Towards Data Science'. Escapes may be the culprit here. I don't see how Leo can be responsible for non-standard unls that various plugins generate. 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/CAMF8tS0ULXFcDtu3puwrvsMxWpgUNmOiCr7_bsg1BU_YJqwf-w%40mail.gmail.com.
Re: Aha: no need for a new paste command
No, I haven't tried it. I'm not even sure I would want to. Think about how the Windows file explorer works. If you copy a file and paste it, it gives the pasted file a name that includes "copy" if there is another file with that name in the same directory. If there isn't another file in the target directory, the copied file gets pasted get the original, unmodified name. File managers on linux work the same way. I'm just saying that Leo ought to act the same way as the file managers where copying nodes are concerned. It's the way way everyone's file manager already works, it's what one would expect, and it's not state-oriented unless you mean the state of whether or not there is an existing name On Saturday, July 8, 2023 at 7:40:10 AM UTC-4 Edward K. Ream wrote: > On Fri, Jul 7, 2023 at 9:35 AM Edward K. Ream wrote: > > > I'm not going to [do a state-oriented paste-node]. > > My apologies. I was too brusque. > > Thomas, have you tried making paste-retaining-clones your default for > ctrl-shift-v? I'm wondering whether you would encounter any problems. > > Thanks. > > 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/24d46380-caa1-4a5e-adf7-75ad397484b2n%40googlegroups.com.
Re: Discuss: remove support (later) for old unls in g.findUnl?
Using the ekr-tweak-unls branch breaks both the bookmarks and zettel tabbed apps. I will look into what isn't working, but in the zettel browser, I see it's looking for and can't find expressions like 'unl://#tom.20220910123825.1', which is not a legacy unl. In the case of the bookmarks manager, it can't find expressions like 'unl://tabbed_bookmarks_manager.leo:#@bookmark-collection (starter set)-->Python-->5 Python GUI Frameworks to Create Desktop, Web, and Even Mobile\xa0Apps. %7C Towards Data Science'. The bookmark and zettel apps that I use every day don't use any of that code because I adapted the old code and wrote it into the apps. So those apps don't call into Leo for these services. However, the versions I shared in leo-editor-contrib are the ones I'm talking about here, and they don't work. On Saturday, July 8, 2023 at 6:13:51 AM UTC-4 Edward K. Ream wrote: > On Fri, Jul 7, 2023 at 9:09 PM Thomas Passin wrote: > >> I've never used g.findUnl() with patterns at all. So as long as the >> newer one picks up legacy-style unls I'd be OK with it. >> > > Hmm. Your plugins might be using g.findUnl indirectly. > > Could you please put a trace at the start of g.findUnl to be sure? I'd > like to know what you discover. > > 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/6c7baebd-c75c-49f5-a734-f1b796660cbfn%40googlegroups.com.
Re: Aha: no need for a new paste command
On Fri, Jul 7, 2023 at 9:35 AM Edward K. Ream wrote: I'm not going to [do a state-oriented paste-node]. My apologies. I was too brusque. Thomas, have you tried making paste-retaining-clones your default for ctrl-shift-v? I'm wondering whether you would encounter any problems. Thanks. 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/CAMF8tS3WUWwAER2wuuuJEU3fbuT4g1wBcb67sr7TR8hELDe%3Daw%40mail.gmail.com.
Re: Discuss: remove support (later) for old unls in g.findUnl?
On Fri, Jul 7, 2023 at 9:09 PM Thomas Passin wrote: > I've never used g.findUnl() with patterns at all. So as long as the > newer one picks up legacy-style unls I'd be OK with it. > Hmm. Your plugins might be using g.findUnl indirectly. Could you please put a trace at the start of g.findUnl to be sure? I'd like to know what you discover. 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/CAMF8tS1_cuBN%2Bmk_nqBpwoWNMUK1m1p8VHzVMkP4xMwz9sUrvw%40mail.gmail.com.
Re: The big PR did remove some gui-related code
On Sat, Jul 8, 2023 at 1:07 AM jkn wrote: > I mentioned it, in the thread "Ctrl-Click on gnx fails if the node is > dirty?" > Thanks for the reminder :-) I've just followed the recipe you gave in that thread. Everything works. And even if everything didn't work, putting gui code in full_match is wrong :-) 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/CAMF8tS3PYx3pedfJNdhe783_0i4kHuowPdDpDZK67OYRjygwCw%40mail.gmail.com.
Re: The big PR did remove some gui-related code
I mentioned it, in the thread "Ctrl-Click on gnx fails if the node is dirty? " On Saturday, July 8, 2023 at 1:14:56 AM UTC+1 Edward K. Ream wrote: > There was some discussion (I don't remember where) about a weird edge > case: changing a clickable link and then undoing the change *without* saving > the file caused Leo not to find the clickable link. > > I dismissed this nit as likely unrelated to the big PR. However, I now see > that the *full_match* helper function (internal to g.findUNL) *did* > contain gui code. Imo removing that code was correct, but there is a chance > that doing so created problems. > > *Summary* > > This post sets the record straight, but I have no intention of restoring > the old code. > > 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/b006e8c5-b7c3-4d74-849f-c4d0551ca505n%40googlegroups.com.
