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 help. 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 element). So there must be another of the changed methods that doesn't quite play right with this. I'll try to track it down tomorrow. -- 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/d3cd4b84-6f3a-4293-aaa3-b7aa8a036f9bn%40googlegroups.com.
Status bar behavior, especially with PR 3215
In the status bar, a right-click brings up a two-item context menu: *Select All* and *Copy*. I have always found this a little confusing. *Copy* implies that it will copy the contents (usually the UNL), but actually you have to select it first before *Copy* will do anything. It's possible to select by dragging the mouse, or by using the *Select All* menu item. With the old style UNLs, there was some value in being able to drag-select only part of the UNL, but with the new-style UNLs I don't see the value. it's all or nothing, it seems to me. How about changing the *Copy* item to *Copy All*, and let it copy the UNL without the need to select anything? could be kept for copying a drag-selected portion. If it is decided to keep the items the way they are, it would be helpful for the *Copy* item to be disabled when nothing has been selected. I don't know how tricky that would be from a Qt programming point of view. -- 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/5164dced-15e7-4417-8157-265e333d2d5bn%40googlegroups.com.
Re: Execute-script in leojs
Lovely! Felix, I have to applaud all this hard and creative work you've been doing! On Monday, June 26, 2023 at 10:26:09 PM UTC-4 Félix wrote: > People have asked about live scripting in leojs in the past (cant remember > who exactly, perhaps Thomas, but I'm not sure) > > That person inquired about javascript live scripting execution in leojs > possibility.. along with the global Leo variables that are expected to be > in the global script namespace / scope, such as g, p, c. > > Not only is it possible, but I can now say it works perfectly fine, and, > I've added the global *vscode* object (see the screenshot, and check the > lower right corner of that screenshot) I might also add two or three more > global objects. (for the most common/useful libraries) > > As I'm polishing and removing the last small bugs before release, I've had > lots of fun trying this out! > > [image: script with vscode global.png] > > Félix > > -- 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/f9a3b75c-4b6f-4cce-b48b-e9936ff3741en%40googlegroups.com.
Execute-script in leojs
People have asked about live scripting in leojs in the past (cant remember who exactly, perhaps Thomas, but I'm not sure) That person inquired about javascript live scripting execution in leojs possibility.. along with the global Leo variables that are expected to be in the global script namespace / scope, such as g, p, c. Not only is it possible, but I can now say it works perfectly fine, and, I've added the global *vscode* object (see the screenshot, and check the lower right corner of that screenshot) I might also add two or three more global objects. (for the most common/useful libraries) As I'm polishing and removing the last small bugs before release, I've had lots of fun trying this out! [image: script with vscode global.png] Félix -- 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/3d43390d-d1a2-4cb4-92ef-71af25e65e0dn%40googlegroups.com.
Re: Code Review, Requirements, and Community Particiation
On Monday, June 26, 2023 at 5:15:45 PM UTC-4 mys...@gmail.com wrote: On Mon, Jun 26, 2023, 13:34 Thomas Passin wrote: In the announcement about the proposed PR 3215 that massively affects UNLs, @Edward wrote "I won't wait for a code review. The code involved is too tricky to understand in an hour or five." This statement contains two red flags. I might be miscounting, but the entire gist of your email appears to only list the one red flag of two tricky to review. I'm curious what you think the second red flag was? 1. No code review; 2. Too tricky. -- 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/26635273-bff9-45cf-96d4-986ab5f91b8en%40googlegroups.com.
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 show legacy or new unls. 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/b1fa9b07-8136-4b76-87fd-96badd509a52n%40googlegroups.com.
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 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/CAMF8tS3Xb0OuoL8fX4KB-%2B0eq4cExLVuvNWR0MBvjJ_X1CCVjg%40mail.gmail.com.
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 this (experimental!) item to the PR's checklist. Furthermore, having the path visible in the status bar could be really > useful > But it hasn't been useful. Alt-N (goto-next-clone) and cff are easy, existing, ways of navigating. In contrast, show-clone-ancestors and show-clone-parents are well worth removing. 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/CAMF8tS1C9zw4FXOGWuWjziTK9KXDr7Eq9a8cvnzq9LuLwmwwNQ%40mail.gmail.com.
Re: leojs alpha
On Mon, Jun 26, 2023 at 2:38 PM jkn wrote: I agree with Thomas that maintaining two codebases in sync is probably and > impossible job in practice. I'm not worried. Leo on the desktop is complete as it is. I trust Félix to bring the Leonine world to vs-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/CAMF8tS299c7siozrLjw%2Bm-D0GFkAbhiKMAaTFtFVYgDjAwbZHw%40mail.gmail.com.
Re: Code Review, Requirements, and Community Particiation
On Mon, Jun 26, 2023 at 2:34 PM Thomas Passin wrote: If we had a proposed set of requirements for a change to fix a well-defined > problem, we probably wouldn't be in the fix we're in right now about this > PR. > We aren't in a fix. We just need to find the least disruptive way of transitioning to the new unls The PR has had a life of its own, driven by exploration, not requirements. The exploration involved simplifying the code and finding the limits of compatibility. The result has been worth two weeks of my life. The PR won't be merged until neither you nor everyone else has any further significant objections. 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/CAMF8tS2Je9at93AJt%3DMn2SHEr%2Bw0TaOh1FH3ypqK0-P2n_iPHw%40mail.gmail.com.
Re: Code Review, Requirements, and Community Particiation
On Mon, Jun 26, 2023 at 2:34 PM Thomas Passin wrote: > In the announcement about the proposed PR 3215 that massively affects > UNLs, @Edward wrote > > "I won't wait for a code review. The code involved is too tricky to > understand in an hour or five." > I'll retract this statement. There have been many good comments already. And I'm glad I waited. Otoh, what I think the code needs most right now is testing. 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/CAMF8tS32nZx3SkGidyagHFzw_SMf5EQSjxKoZKB4QT7vXnWjGQ%40mail.gmail.com.
Re: Code Review, Requirements, and Community Particiation
On Mon, Jun 26, 2023, 13:34 Thomas Passin wrote: > In the announcement about the proposed PR 3215 that massively affects > UNLs, @Edward wrote > > "I won't wait for a code review. The code involved is too tricky to > understand in an hour or five." > > This statement contains two red flags. > I might be miscounting, but the entire gist of your email appears to only list the one red flag of two tricky to review. I'm curious what you think the second red flag was? In my opinion a red flag of 'pushing through a change without review' regardless of supporting reasoning, comes up well before the complexity of the code. I think it's antithetical to the open source mantra, even with a BDFL in place who gets to make the final decision on things, to simply push a change through without even asking for comment. If it's too tricky for a code review, there's something out of whack > somewhere. The answer isn't to skip code review, it's to figure out how to > make it more accessible so that it *can* be commented on and reviewed. > And also perhaps not assume that people would not understand the code, even if it's tricky there is a good potential that at least a few people might be able to understand what the changes imply. Mike -- 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/CAN%2B%2B4hHQMw0YC%2BGtc3Xa_%3DmVM833Szd59tMpL3KbHuK4V_g0eA%40mail.gmail.com.
Re: leojs alpha
haha! don't worry - Leo is Leo and LeoJS is it's own thing :)
But who knows what the future holds for Leo, LeoInteg and LeoJS?
Thanks again for your input! People's ideas and suggestions on this forum
are what fueled my motivation to code all of this!
Félix
On Monday, June 26, 2023 at 3:38:56 PM UTC-4 jkn wrote:
> Hi Félix
>
> Thanks for the extra information. That does sound like a lot of work, I
> (too) am impressed with your dedication. But I agree with Thomas that
> maintaining two codebases in sync is probably and impossible job in
> practice.
>
> I would kinda-hate Leo to end up as a javascript (/typescript) app instead
> of a Python one ... but I am also very interested in seeing the results. I
> will try to be a beta tester for you ;-)
>
> Regards, J^n
>
> On Monday, June 26, 2023 at 7:14:36 PM UTC+1 Félix wrote:
>
>> Hi jkn! :D
>>
>> Thanks for your interest and questions!
>>
>> I've translated/transliterated (not sure which is appropriate!) about 99%
>> myself manually, and I've used chatGPT for small parts (e.g. some regular
>> expressions, some small quirky methods) which I would estimate to be 1% of
>> the code. (anyways - from 2021 to early 2023 chatGPT did not even exist!)
>>
>> Even then, the parts translated with AI had to be manually inspected and
>> tested. (I've played a lot with chatGPT translations from python to
>> typescript and it does not account for subtle details in some "almost
>> identical" native functions, which inevitably break the intended behavior)
>> In fact, the more important and subtle a detail is, the more likely it is
>> that AI will ignore it. (which may even compile and run in normal cases,
>> but break in edge/extreme cases)
>>
>> For example, regex (Leo uses those a lot in critical places) have subtle
>> differences in the usage of 'flags' such as 'm' or 'g' in python vs
>> javascript, which will totally fail if not taken into account.
>>
>> So it's really risky to use AI for translation. (if not thoroughly
>> inspected and tested)
>>
>> About the 'upstream' work on Leo - I did the oldest, less likely to
>> change code first. Also, I have not done the importers yet, nor the unl
>> support, which happen to be re-written or changed in the last few weeks
>> hehe !
>>
>> For other stuff that changed, I try to keep up by collaborating with
>> Edward to change Leojs & match Leo's changes as quickly as possible, as to
>> not fall to much behind.
>>
>> I look in the commit history and diffs with tools in gitlens (vscode
>> extension) to keep up with the changes and modify leojs as much as possible.
>>
>> I usually work on implementing stuff for 2-3 weeks ,and then spend a week
>> to catch up with what was updated by Edward (if it happens to be on stuff
>> already in leojs).
>>
>> Thanks for your support and curiosity! Best to you - Hope you'll be
>> testing & reporting bugs when I release the first beta in a few days (or
>> weeks)! ;)
>>
>> Félix
>>
>>
>> On Monday, June 26, 2023 at 10:09:17 AM UTC-4 jkn wrote:
>>
>>> Hi Felix - something I've missed in the exciting mentions re. leojs
>>> here. Is the 'transliteration' done manually ('after coding for a few
>>> years'...) or via some (semi'?)-automated process?
>>>
>>> If the former, I'm wondering how 'upstream' work on Leo gets
>>> incorporated. If the latter, I'm curious about the process...
>>>
>>> Thanks & Regards, J^n
>>>
>>>
>>> On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:
>>>
Thanks Arjan!!
Simple encouragements and feedback means a lot to me!
Félix
On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
> > After coding for a few years
>
> Awesome perseverance. I've just continued using regular Leo because
> I'm used to the workflow, but I hope to find some time to play with the
> newer developments. Good luck!
>
> On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
>
>> > ...So anywhere from a week or two, or a month or two, hard to say,
>> but it's going to be this summer! :D
>>
>> Assuming vs-code allows it, I encourage you to release an alpha
>> version asap. There is nothing wrong with a list of known bugs.
>>
>> 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/86ade383-c241-4b81-892f-4a79d6528cd6n%40googlegroups.com.
Re: Code Review, Requirements, and Community Particiation
I'm not going to go too far down this rabbit hole - I have a day job - but in general I would agree that 'too tricky to understand' code is a red flag. On Monday, June 26, 2023 at 8:34:47 PM UTC+1 tbp1...@gmail.com wrote: > In the announcement about the proposed PR 3215 that massively affects > UNLs, @Edward wrote > > "I won't wait for a code review. The code involved is too tricky to > understand in an hour or five." > > This statement contains two red flags. If it's too tricky for a code > review, there's something out of whack somewhere. The answer isn't to skip > code review, it's to figure out how to make it more accessible so that it > *can* be commented on and reviewed. > > One important aspect of that is having requirements. If we had a proposed > set of requirements for a change to fix a well-defined problem, we probably > wouldn't be in the fix we're in right now about this PR. The Leo community > could have commented on the requirements and perhaps suggested changes. > True, I seem to be the only part of the community that has responded, but > maybe others would have. > > Then changes could have proposed and it could be explained how they would > work to satisfy the requirements. And once that all seemed all right, then > tests could have ben written, the details could have been implemented and > tested. > > I'm not suggesting that written requirements would be needed for minor > changes or bug fixes. But for something which is too complicated to > review? And without requirements, you can't really write proper tests, > either The way it has worked in this case, the "requirements" live in one > person's head, are not very well specified, and are subject to rapid > change. (I'm like that, too! But sometimes, I do write requirements just > for myself.) > > Yes, it might have taken longer to formulate some requirements and let the > community digest and comment on them. But there was no need for speed. > The impetus for this was not a critical bug. There was no need to rush > major, breaking changes. > > If I had seen some requirements, I would have asked to add one similar to > this - > > *Backwards Compatibility* > 1. Existing UNL-consuming code shall work without changes. > 2. CTRL-Click navigation to legacy UNLs shall continue to work > correctly. > 3. The status bar shall continue to display a representation of the > path to the selected node. > > Now, maybe item 1. wouldn't be possible. Then we could have had a > discussion about why not, and how to handle using the new UNLs with > existing functions. We could have changed that requirement to make it > clear what was supposed to be accomplished. If we had a sketch of proposed > changes, we could have seen where method signatures were changed, and if > that had been intended or a mistake. > > All this would have made Felix's life easier, too! And I imagine that he > would have had some good input to contribute. > -- 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/ab80e178-958f-4400-a5ab-090b3de90ccdn%40googlegroups.com.
Re: leojs alpha
Hi Félix
Thanks for the extra information. That does sound like a lot of work, I
(too) am impressed with your dedication. But I agree with Thomas that
maintaining two codebases in sync is probably and impossible job in
practice.
I would kinda-hate Leo to end up as a javascript (/typescript) app instead
of a Python one ... but I am also very interested in seeing the results. I
will try to be a beta tester for you ;-)
Regards, J^n
On Monday, June 26, 2023 at 7:14:36 PM UTC+1 Félix wrote:
> Hi jkn! :D
>
> Thanks for your interest and questions!
>
> I've translated/transliterated (not sure which is appropriate!) about 99%
> myself manually, and I've used chatGPT for small parts (e.g. some regular
> expressions, some small quirky methods) which I would estimate to be 1% of
> the code. (anyways - from 2021 to early 2023 chatGPT did not even exist!)
>
> Even then, the parts translated with AI had to be manually inspected and
> tested. (I've played a lot with chatGPT translations from python to
> typescript and it does not account for subtle details in some "almost
> identical" native functions, which inevitably break the intended behavior)
> In fact, the more important and subtle a detail is, the more likely it is
> that AI will ignore it. (which may even compile and run in normal cases,
> but break in edge/extreme cases)
>
> For example, regex (Leo uses those a lot in critical places) have subtle
> differences in the usage of 'flags' such as 'm' or 'g' in python vs
> javascript, which will totally fail if not taken into account.
>
> So it's really risky to use AI for translation. (if not thoroughly
> inspected and tested)
>
> About the 'upstream' work on Leo - I did the oldest, less likely to change
> code first. Also, I have not done the importers yet, nor the unl support,
> which happen to be re-written or changed in the last few weeks hehe !
>
> For other stuff that changed, I try to keep up by collaborating with
> Edward to change Leojs & match Leo's changes as quickly as possible, as to
> not fall to much behind.
>
> I look in the commit history and diffs with tools in gitlens (vscode
> extension) to keep up with the changes and modify leojs as much as possible.
>
> I usually work on implementing stuff for 2-3 weeks ,and then spend a week
> to catch up with what was updated by Edward (if it happens to be on stuff
> already in leojs).
>
> Thanks for your support and curiosity! Best to you - Hope you'll be
> testing & reporting bugs when I release the first beta in a few days (or
> weeks)! ;)
>
> Félix
>
>
> On Monday, June 26, 2023 at 10:09:17 AM UTC-4 jkn wrote:
>
>> Hi Felix - something I've missed in the exciting mentions re. leojs here.
>> Is the 'transliteration' done manually ('after coding for a few years'...)
>> or via some (semi'?)-automated process?
>>
>> If the former, I'm wondering how 'upstream' work on Leo gets
>> incorporated. If the latter, I'm curious about the process...
>>
>> Thanks & Regards, J^n
>>
>>
>> On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:
>>
>>> Thanks Arjan!!
>>>
>>> Simple encouragements and feedback means a lot to me!
>>>
>>> Félix
>>>
>>> On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
>>>
> After coding for a few years
Awesome perseverance. I've just continued using regular Leo because I'm
used to the workflow, but I hope to find some time to play with the newer
developments. Good luck!
On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
> > ...So anywhere from a week or two, or a month or two, hard to say,
> but it's going to be this summer! :D
>
> Assuming vs-code allows it, I encourage you to release an alpha
> version asap. There is nothing wrong with a list of known bugs.
>
> 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/bcddcf31-b89e-4235-9608-9b3484ba9c46n%40googlegroups.com.
Code Review, Requirements, and Community Particiation
In the announcement about the proposed PR 3215 that massively affects UNLs, @Edward wrote "I won't wait for a code review. The code involved is too tricky to understand in an hour or five." This statement contains two red flags. If it's too tricky for a code review, there's something out of whack somewhere. The answer isn't to skip code review, it's to figure out how to make it more accessible so that it *can* be commented on and reviewed. One important aspect of that is having requirements. If we had a proposed set of requirements for a change to fix a well-defined problem, we probably wouldn't be in the fix we're in right now about this PR. The Leo community could have commented on the requirements and perhaps suggested changes. True, I seem to be the only part of the community that has responded, but maybe others would have. Then changes could have proposed and it could be explained how they would work to satisfy the requirements. And once that all seemed all right, then tests could have ben written, the details could have been implemented and tested. I'm not suggesting that written requirements would be needed for minor changes or bug fixes. But for something which is too complicated to review? And without requirements, you can't really write proper tests, either The way it has worked in this case, the "requirements" live in one person's head, are not very well specified, and are subject to rapid change. (I'm like that, too! But sometimes, I do write requirements just for myself.) Yes, it might have taken longer to formulate some requirements and let the community digest and comment on them. But there was no need for speed. The impetus for this was not a critical bug. There was no need to rush major, breaking changes. If I had seen some requirements, I would have asked to add one similar to this - *Backwards Compatibility* 1. Existing UNL-consuming code shall work without changes. 2. CTRL-Click navigation to legacy UNLs shall continue to work correctly. 3. The status bar shall continue to display a representation of the path to the selected node. Now, maybe item 1. wouldn't be possible. Then we could have had a discussion about why not, and how to handle using the new UNLs with existing functions. We could have changed that requirement to make it clear what was supposed to be accomplished. If we had a sketch of proposed changes, we could have seen where method signatures were changed, and if that had been intended or a mistake. All this would have made Felix's life easier, too! And I imagine that he would have had some good input to contribute. -- 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/2eaa6d8b-c6aa-43d6-91f7-3bd25459575cn%40googlegroups.com.
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" 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/37232343-8c39-4832-b21f-e904d85c6d45n%40googlegroups.com.
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 open a window, then searched in the window. 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. Furthermore, having the path visible in the status bar could be really useful For example, a search might return several hits for a def. You navigate to one or another of them. But wait! It might be in a plugin instead of the core. You can't tell by looking at the tree because too many nodes are open and you can't see what file or class you are in. But a glance at the (legacy) unl in the status line would tell you. The new way loses that capability. To me, that's a real loss. -- 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/2f74db95-1cd5-4f19-867e-9541b71731a3n%40googlegroups.com.
Re: leojs alpha
On Monday, June 26, 2023 at 10:09:17 AM UTC-4 jkn wrote: If the former, I'm wondering how 'upstream' work on Leo gets incorporated. If the latter, I'm curious about the process... Keeping two code bases synchronized is nearly impossible in the long run. Each one evolves in its own way, and the second is almost always some revisions behind the first. I remember reading an article years ago about an US Air Force effort to see if a particular newer methodology for software development was superior the their existing process. The USAF got convinced to have a team try to duplicate an existing system, which I think (IIRC) was a fire control module for a particular jet fighter. The team got to work, but by the time they had it working, the module in use had evolved new capability. The team was never able to catch up with the version in use. So the test of methodologies was never able to be completed, and no product was ever produced with its results. Leo may not be as complicated, but the principle remains. And as LeoJS gets into use, its users will start wanting and adding new features that aren't in Leo itself. The two products will diverge over time. There's nothing wrong with this, it's just the way things work. The more that new features can be added as plugins, the less the cores will tend to diverge. -- 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/ebdf93ca-8305-4ed9-afec-0763f37d233fn%40googlegroups.com.
Re: Leo active file bug and how to get the content of unl
On Mon, Jun 26, 2023 at 12:57 PM Thomas Passin wrote: Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears > in both g.findUNL and g.findGNX. So these calls have already been done when > g.handleUnl returns. > > > That's not the point. This bit of code returns the focus to the *original* > node even if the findUNL() call, for a UNL pointing into another outline, > had changed the focus to that other outline. The idea is to retrieve the > body of the node addressed by the unl without changing the focus. > And my point was the PR will break as little as possible. 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/CAMF8tS2GFGiND%2BtFqzmoNqfAuJPe%3DJXG7TxiKU9-Lvi%2BPu734Q%40mail.gmail.com.
Re: Leo active file bug and how to get the content of unl
On Mon, Jun 26, 2023 at 12:56 PM Thomas Passin wrote: 1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true. > > Yes it has. Here's the docstring from the (unreplaced) g.findUNL: > > Find and move to the unl given by the unlList in the commander c. >Return the found position, or None. > The unlList is a list of headlines. Even if the top headline is an @file node, there is no way for the legacy g.findUNL code to open another commander. In other words, you are misunderstanding the docstring. The legacy g.*find*UNL does not work the way you think it does. The legacy g.*handle*Unl function *could*open other outlines, but only in limited places. I removed that code because it was too Leo-specific. 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/CAMF8tS2nEh6jZ37crf0rVyriJtZFKpDS2Pixbb7dVHuYFYiFYA%40mail.gmail.com.
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 make everything right. 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 open a window, then searched in the window. One path was g.app.homeDir, so maybe part of the code should be reinstated. I'll investigate. 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 help. 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/CAMF8tS2pDRAk5Gp7KOZVzNTVbTtE2iKJBZ%3DtOXUavfEzR5TmEA%40mail.gmail.com.
Re: leojs alpha
Hi jkn! :D
Thanks for your interest and questions!
I've translated/transliterated (not sure which is appropriate!) about 99%
myself manually, and I've used chatGPT for small parts (e.g. some regular
expressions, some small quirky methods) which I would estimate to be 1% of
the code. (anyways - from 2021 to early 2023 chatGPT did not even exist!)
Even then, the parts translated with AI had to be manually inspected and
tested. (I've played a lot with chatGPT translations from python to
typescript and it does not account for subtle details in some "almost
identical" native functions, which inevitably break the intended behavior)
In fact, the more important and subtle a detail is, the more likely it is
that AI will ignore it. (which may even compile and run in normal cases,
but break in edge/extreme cases)
For example, regex (Leo uses those a lot in critical places) have subtle
differences in the usage of 'flags' such as 'm' or 'g' in python vs
javascript, which will totally fail if not taken into account.
So it's really risky to use AI for translation. (if not thoroughly
inspected and tested)
About the 'upstream' work on Leo - I did the oldest, less likely to change
code first. Also, I have not done the importers yet, nor the unl support,
which happen to be re-written or changed in the last few weeks hehe !
For other stuff that changed, I try to keep up by collaborating with
Edward to change Leojs & match Leo's changes as quickly as possible, as to
not fall to much behind.
I look in the commit history and diffs with tools in gitlens (vscode
extension) to keep up with the changes and modify leojs as much as possible.
I usually work on implementing stuff for 2-3 weeks ,and then spend a week
to catch up with what was updated by Edward (if it happens to be on stuff
already in leojs).
Thanks for your support and curiosity! Best to you - Hope you'll be testing
& reporting bugs when I release the first beta in a few days (or weeks)! ;)
Félix
On Monday, June 26, 2023 at 10:09:17 AM UTC-4 jkn wrote:
> Hi Felix - something I've missed in the exciting mentions re. leojs here.
> Is the 'transliteration' done manually ('after coding for a few years'...)
> or via some (semi'?)-automated process?
>
> If the former, I'm wondering how 'upstream' work on Leo gets incorporated.
> If the latter, I'm curious about the process...
>
> Thanks & Regards, J^n
>
>
> On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:
>
>> Thanks Arjan!!
>>
>> Simple encouragements and feedback means a lot to me!
>>
>> Félix
>>
>> On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
>>
>>> > After coding for a few years
>>>
>>> Awesome perseverance. I've just continued using regular Leo because I'm
>>> used to the workflow, but I hope to find some time to play with the newer
>>> developments. Good luck!
>>>
>>> On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
>>>
> ...So anywhere from a week or two, or a month or two, hard to say,
but it's going to be this summer! :D
Assuming vs-code allows it, I encourage you to release an alpha version
asap. There is nothing wrong with a list of known bugs.
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/e5a888a6-326c-4f3b-aba9-233a5c78e9e9n%40googlegroups.com.
Re: Leo active file bug and how to get the content of unl
On Monday, June 26, 2023 at 1:47:07 PM UTC-4 Edward K. Ream wrote: On Sun, Jun 25, 2023 at 10:22 AM Thomas Passin wrote: > Great! And if you want to do the same for a UNL in another outline, you can add these two lines (at least until that PR gets merged; I don't know about after that): # Add this after the "content =" line. if c2 is not c0: g.app.selectLeoWindow(c0) Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears in both g.findUNL and g.findGNX. So these calls have already been done when g.handleUnl returns. That's not the point. This bit of code returns the focus to the *original* node even if the findUNL() call, for a UNL pointing into another outline, had changed the focus to that other outline. The idea is to retrieve the body of the node addressed by the unl without changing the focus. -- 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/43ceabdc-61a2-4539-8bd9-be7dc93c8611n%40googlegroups.com.
Re: Leo active file bug and how to get the content of unl
On Monday, June 26, 2023 at 1:29:24 PM UTC-4 Edward K. Ream wrote: On Sun, Jun 25, 2023 at 7:51 AM Thomas Passin wrote: "Remove support for cross-file UNLs" - WTF??? This will break some of my scripts. How are we going to navigate to other outlines by UNL? Wasn't that half of the point of having UNLs in the first place? This conversation is likely out of date: 1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true. Yes it has. Here's the docstring from the (unreplaced) g.findUNL: Find and move to the unl given by the unlList in the commander c. Return the found position, or None. -- 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/a71e6703-f802-4478-af05-de24062e39fcn%40googlegroups.com.
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 zettelkasten apps partially work but not completely. I will look at using these new "legacy" methods next. On Monday, June 26, 2023 at 1:21:07 PM UTC-4 Edward K. Ream wrote: > 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 returned position is in the same outline! Do something like this: > > p = g.findUNL(unlList, c) > # Do not assume that p is in c. > if p: > c2 = p.v.context > c2.redraw(p) > > 2. g.handleUnl contains code similar to that shown above, so the warning > applies only to writers of plugins. > > 3. g.findUNL no longer does *any* gui-related operations. It was never a > clever idea. > > 4. No, I won't add a kwarg to g.findUNL that suppress other-outline > searches. > > EKR > -- 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/ff781c0d-dfd4-4791-ae25-68bb088e41ffn%40googlegroups.com.
Re: Leo active file bug and how to get the content of unl
On Sun, Jun 25, 2023 at 10:22 AM Thomas Passin wrote: > Great! And if you want to do the same for a UNL in another outline, you can add these two lines (at least until that PR gets merged; I don't know about after that): # Add this after the "content =" line. if c2 is not c0: g.app.selectLeoWindow(c0) Oh ye of little faith. In the PR the call to g.app.selectLeoWindow appears in both g.findUNL and g.findGNX. So these calls have already been done when g.handleUnl 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/CAMF8tS3Wd%2BRPk1coKfC3--4%3DXkJXQZoM%3D3hs%2B7sdC9q7f1CDKw%40mail.gmail.com.
Re: Leo active file bug and how to get the content of unl
On Mon, Jun 26, 2023 at 12:32 PM Edward K. Ream wrote: > Oops! In the PR g.handleUNL returns None. I'll restore the legacy operation immediately. Done. g.handleUNL returns a commander or None, exactly as in devel. 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/CAMF8tS3jo2fD0dwB_Vp5u5-6q-Qj4DazawkKFt25BB1rTrD6iA%40mail.gmail.com.
Re: Leo active file bug and how to get the content of unl
On Sun, Jun 25, 2023 at 8:05 AM Thomas Passin wrote: > Assuming that these commands will continue to work after the PR: c0, p0 = c, c.p c2 = g.handleUnl(unl, c) Oops! In the PR g.handleUNL returns None. I'll restore the legacy operation immediately. 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/CAMF8tS03fMW33sqZE9i-3u_k4ZzTqV7ujWBKf2Wz5eBULs6y%3Dg%40mail.gmail.com.
Re: Leo active file bug and how to get the content of unl
On Sun, Jun 25, 2023 at 7:51 AM Thomas Passin wrote: > "Remove support for cross-file UNLs" - WTF??? This will break some of my > scripts. How are we going to navigate to other outlines by UNL? Wasn't > that half of the point of having UNLs in the first place? This conversation is likely out of date: 1.I was probably thinking that g.findUNL (the legacy unl-finding function) might return a position in another outline. To my knowledge, that has never been true. 2. The PR continues to support *all* legacy unls. As before, g.findUNL simply ignores the "file part", that is everything before the '#'. 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/CAMF8tS3bPmBVJuD_rumX9QY3__3JNVdSVf9Y1dXeZA4oXacZ_Q%40mail.gmail.com.
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 returned position is in the same outline! Do something like this: p = g.findUNL(unlList, c) # Do not assume that p is in c. if p: c2 = p.v.context c2.redraw(p) 2. g.handleUnl contains code similar to that shown above, so the warning applies only to writers of plugins. 3. g.findUNL no longer does *any* gui-related operations. It was never a clever idea. 4. No, I won't add a kwarg to g.findUNL that suppress other-outline searches. EKR -- 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/3e3003c0-4992-41bf-9bc2-d9acedd1aeafn%40googlegroups.com.
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 provide that capability, whether or not they are called > "new style unls". Pre-change unls, OTOH, are ideal and require almost no > tinkering with to achieve those requirements. If Leo won't support those > capabilities, the the bookmarks manager needs to compute the equivalent, > and the obsoleted Leo methods already do that. So it's easier for me to > use them than to re-create their capability from scratch. > > The zettelkasten machinery runs on gnxs and should be less affected if at > all. But I have a host of nodes that include unl links to other outlines, > and none of those links would work any more. Some supporting commands do > things like getting the unl of a node and copying it to the clipboard. > Maybe those would still work, maybe they wouldn't. I'll have to see. > Thanks for the clarification. All your existing unls should now work. Please test the branch and report any problems. *About the name, p.get_UNL* The more I think about this question, the more tricky it becomes. The PR previously did use the scheme you proposed. But I want p.get_UNL to change so that legacy code will use the *new *unls. In other words, the underlying issue is about compatibility, not names. *New methods* I'll create two new methods for use by plugins such as yours: *p.get_legacy_UNL* will return what g.get_UNL used to return. *p.get_short_legacy_UNL* will return a headline-oriented unl, omitting the file name component (everything up to and including the '#'). *Note: *g.findUNL never did anything useful with the file name! *Better searching* The new g.findGNX searches all open outlines for nodes with the given gnx. * g.findUNL can use the same scheme!* *Summary* p.get_UNL should return gnx-oriented unls so that existing code will automatically use non-breakable gnxs. 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. Please test your plugins. I'll fix any compatibility problems before merging the PR. 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/CAMF8tS1M7W3J%3DK%3DkPRaBRnmJRUCy_ErLk4CHkLUpDAcVsgNFZQ%40mail.gmail.com.
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 should if they use the new g.handleUnl(). 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 provide that capability, whether or not they are called "new style unls". Pre-change unls, OTOH, are ideal and require almost no tinkering with to achieve those requirements. If Leo won't support those capabilities, the the bookmarks manager needs to compute the equivalent, and the obsoleted Leo methods already do that. So it's easier for me to use them than to re-create their capability from scratch. The zettelkasten machinery runs on gnxs and should be less affected if at all. But I have a host of nodes that include unl links to other outlines, and none of those links would work any more. Some supporting commands do things like getting the unl of a node and copying it to the clipboard. Maybe those would still work, maybe they wouldn't. I'll have to see. -- 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/95a8db1d-fe54-411d-a73f-192e0ef35a5an%40googlegroups.com.
Re: leojs alpha
Hi Felix - something I've missed in the exciting mentions re. leojs here.
Is the 'transliteration' done manually ('after coding for a few years'...)
or via some (semi'?)-automated process?
If the former, I'm wondering how 'upstream' work on Leo gets incorporated.
If the latter, I'm curious about the process...
Thanks & Regards, J^n
On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:
> Thanks Arjan!!
>
> Simple encouragements and feedback means a lot to me!
>
> Félix
>
> On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
>
>> > After coding for a few years
>>
>> Awesome perseverance. I've just continued using regular Leo because I'm
>> used to the workflow, but I hope to find some time to play with the newer
>> developments. Good luck!
>>
>> On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
>>
>>> > ...So anywhere from a week or two, or a month or two, hard to say, but
>>> it's going to be this summer! :D
>>>
>>> Assuming vs-code allows it, I encourage you to release an alpha version
>>> asap. There is nothing wrong with a list of known bugs.
>>>
>>> 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/a18dde03-fcf3-461d-af01-e91985fa78cfn%40googlegroups.com.
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 unls (in the body pane) in a variety of formats. Please let me know if there are other formats that should be tested. Edward P.S. The old/unchanged g.findUNL ignores file names and finds (legacy) unls only in the present outline. I plan to extend the search to all open outlines, as in g.findGNX. EKR -- 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/579d5788-ca21-4b78-a40a-3479f246ae25n%40googlegroups.com.
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 important as how Leo's code (including plugins) use the method. 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/CAMF8tS2eMtCcA3WFyLEmqf7fZDBFrM82N%2Bid7%2BUrxg7RbbqARw%40mail.gmail.com.
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 in my bookmarks manager. > I hope you won't have to do this. I'm going to restore g.findUNL() and hook it back into g.handleUnl(). Restoring the old code and the legacy operation should be complete sometime today. At that point your bookmarks and zettelkasten should work as before in the ekr-3181-mypy-links branch. Let me know if they don't. 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 should if they use the new g.handleUnl(). Edward P.S. Restoring g.findUNL() will also improve the convert-unls command. EKR -- 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/CAMF8tS389TEyZ5dF3vu5tX%2BYktGk_wW5fSh4g7Z%3D9ipfq7jv-Q%40mail.gmail.com.
