Re: Discuss: remove support (later) for old unls in g.findUnl?

[Thomas Passin]

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.

On Friday, July 7, 2023 at 7:36:26 PM UTC-4 Edward K. Ream wrote:

> g.findUnl is the handler for path-based unls. It contains two regex 
> patterns:
>
> # (file_name):(comma-separated list of node indices) 
> old_pat = re.compile(r'^(.*):(\d+),?(\d+)?,?([-\d]+)?,?(\d+)?$')
>
> # (file_name)::(line_number).
> new_pat = re.compile(r'^(.*?)(::)([-\d]+)?$')
>
> Leo's present unit tests cover only the new pattern.
>
> Notice the inconsistencies in the old regex. Does anyone still use it?
>
> Removing the old regex would eliminate other strange code. leoJS would 
> benefit.
>
> g.findUnl will remain unchanged for Leo 6.7.4.
>
> Your comments, please.
>
> 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/7fb25a80-ff2d-43a8-99f5-35619d6ec89dn%40googlegroups.com.

The big PR did remove some gui-related code

[Edward K. Ream]

 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/6b2b466a-e2d9-42a4-b10b-910d750aba55n%40googlegroups.com.

Discuss: remove support (later) for old unls in g.findUnl?

[Edward K. Ream]

g.findUnl is the handler for path-based unls. It contains two regex 
patterns:

# (file_name):(comma-separated list of node indices) 
old_pat = re.compile(r'^(.*):(\d+),?(\d+)?,?([-\d]+)?,?(\d+)?$')

# (file_name)::(line_number).
new_pat = re.compile(r'^(.*?)(::)([-\d]+)?$')

Leo's present unit tests cover only the new pattern.

Notice the inconsistencies in the old regex. Does anyone still use it?

Removing the old regex would eliminate other strange code. leoJS would 
benefit.

g.findUnl will remain unchanged for Leo 6.7.4.

Your comments, please.

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/40ba6063-0ec1-492a-bc29-74b98337b316n%40googlegroups.com.

Re: Leo 6.7.4 on schedule for Friday, July 14

[Edward K. Ream]

On Friday, July 7, 2023 at 9:43:38 AM UTC-5 Edward K. Ream wrote:

> I still expect to release 6.7.4 one week from today.

Leo 6.7.4 should suffice as the foundation of leoJS.

I plan to release 6.7.5 in December of this year or earlier if Félix 
requests doing so.

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/2af0a80b-63ab-486b-a3c8-1787d1312eefn%40googlegroups.com.

Re: Aha: no need for a new paste command

[Edward K. Ream]

On Friday, July 7, 2023 at 9:35:51 AM UTC-5 Edward K. Ream wrote:

> I'm not going to do this...I've closed this PR and am not likely to 
reopen it.

As always,  you can write a plugin that makes Leo work exactly as you want. 
You do not need my permission :-)  Note the preread code in the PR. It 
eliminates the need to override Leo's existing commands.

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/96121f01-0b5a-4289-92f3-173fc263e30fn%40googlegroups.com.

Re: Leo 6.7.4 on schedule for Friday, July 14

[Edward K. Ream]

On Tuesday, July 4, 2023 at 9:11:18 AM UTC-5 Edward K. Ream wrote:

We have 10 days to test the big PR. I expect no significant problems.


I still expect to release 6.7.4 one week from today.


A lot has happened in the last three days, but the tweaks PR 
 now contains *fewer*
 changes.


I have pushed several issues to 6.7.5. Those that remain are small and 
uncontroversial.

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/40d31d0c-c747-478a-88bb-73d08fb4b91cn%40googlegroups.com.

Re: Aha: no need for a new paste command

[Edward K. Ream]

On Friday, July 7, 2023 at 7:55:29 AM UTC-5 Thomas wrote:

I got some more clarity about this, and I commented the following on the 
proposed PR:


I can now see that the concept of operation is simple. Within an outline, 
for a parent-and-subtree:

   - Ask for a move, get a move; gnxs do not change;
   - Cut-paste is the same as a move;
   - Ask for a copy, get a copy, meaning all nodes get new gnxs.
   - To paste a copy when the top of the copied tree already exists means *by 
   definition* to ask for a copy.

I think that Leo's defaults should act this way. 


I'm not going to do this. See the comments in the PR. I've closed this PR 
and am not likely to reopen it.

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/ac1a1dd9-7d81-4972-abb4-e4355e4502d8n%40googlegroups.com.

The tweaks PR is coming soon

[Edward K. Ream]

 

PR #3424  now contains 
the following changes:


1. The default settings in leoSettings.leo are:


@string unl-status-kind = gnx

@bool full-unl-paths = False


2. *g.openUNLFile* fully supports absolute paths and resolves relative 
paths more carefully.


3. test.leo contains tests of unls with absolute paths. Naturally, those 
tests will only work on my machine. They do work :-)


4. Terry's gnx, tbrown.20111010104549.26758, now identifies 
p.get_full_legacy_UNL. Previously it identified p.get_UNL. 


*Summary*


PR #3424  contains only 
one significant change, namely to *g.openUNLFile*. This PR leaves p.get_UNL 
unchanged.


I'll merge this PR on Monday, July 10, or before if Thomas approves.


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/7626ddb1-2281-44c7-b2e5-accef5265affn%40googlegroups.com.

Re: Aha: no need for a new paste command

[Thomas Passin]

I got some more clarity about this, and I commented the following on the 
proposed PR:

I can now see that the concept of operation is simple. Within an outline, 
for a parent-and-subtree:

   - Ask for a move, get a move; gnxs do not change;
   - Cut-paste is the same as a move;
   - Ask for a copy, get a copy, meaning all nodes get new gnxs.
   - To paste a copy when the top of the copied tree already exists means *by 
   definition* to ask for a copy.

I think that Leo's defaults should act this way.  I'd rather that the 
behaviors not change via a setting because their effect can be invisible 
until later, when it might be too late.  Also, those of us who run several 
installations (for instance, on a Linux VM for testing purposes) would 
inevitably forget what state those settings were on what machine.  That 
might end up being very confusing, to say the least!

Once we're sure that the paste-copy and paste-clone commands are working as 
intended, then we can probably make it fairly clear by naming commands and 
menu items (and also in the docstrings) as to what to expect.
On Friday, July 7, 2023 at 7:15:38 AM UTC-4 Edward K. Ream wrote:

> On Friday, July 7, 2023 at 3:59:49 AM UTC-5 Edward K. Ream wrote:
>
> > I'll leave #3429  
> > open 
> while we continue our discussion.
>
> I have assigned this issue to Leo 6.7.5. No way will this issue be part of 
> 6.7.4.
>
> 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/32a449d4-b64f-4981-b492-1376b6bac4e6n%40googlegroups.com.

Re: Aha: no need for a new paste command

[Edward K. Ream]

On Friday, July 7, 2023 at 3:59:49 AM UTC-5 Edward K. Ream wrote:

> I'll leave #3429  open 
while we continue our discussion.

I have assigned this issue to Leo 6.7.5. No way will this issue be part of 
6.7.4.

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/aea0145a-9c60-4f26-8b8c-5ccb73afdac2n%40googlegroups.com.

Re: Aha: no need for a new paste command

[Edward K. Ream]

On Fri, Jul 7, 2023 at 5:42 AM jkn  wrote:

> I currently only see command paste-retaining-clones. Is this the command
> you are referring to (not paste-node-retaining-clones)?
>

Yes. I misspelled the name of the command.

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/CAMF8tS2C-0ujoj%3DVbABipTaCLpJVqN0_TpGaEfOFcw%2BBCMYFQw%40mail.gmail.com.

Re: Aha: no need for a new paste command

[jkn]

I currently only see command paste-retaining-clones. Is this the command 
you are referring to (not paste-node-retaining-clones)?

I presume this is an older command (that I have not knowingly used).

I guess I am still ... nervous is not exactly the right word ... about 
having variants for what I think most users would see as a fundamental, and 
"trivial", operation. But I am trying to keep an open mind...

J^n



On Friday, July 7, 2023 at 9:59:49 AM UTC+1 Edward K. Ream wrote:

> #3429  suggests 
> that Leo's paste-node command should retain gnxs if doing so would create 
> no gnx clashes in the pasted node.
>
>
> Thomas, Félix and I have been debating what *anyGnxClashes *should check. 
> Should it check the entire pasted tree or only its root? Depending on the 
> answer, the paste-node will act like Leo's *legacy *paste-node or 
> paste-node-retaining-clones commands.
>
>
> *Aha!* The contents of the target outline don't matter! *What matters is 
> the user's intention*.
>
>
> Thomas uses cut-node/pastes-node mostly to move outlines. For him, 
> paste-node-retaining-clones is likely the best binding for ctrl-shift-v.
>
>
> But I typically use copy-node/paste-node to cherry-pick outlines from 
> other branches. For me, paste-node is the best binding.
>
>
> *Summary*
>
>
> When using paste-node, the user won't know what anyGnxClashes will return. 
> That can't be good!
>
>
> *Aha*: it *shouldn't matter* what nodes are in the target outline. What 
> matters is whether the user *wants *to regain gnxs!
>
>
> Users who regularly use copy-node/paste to move nodes may find it best to 
> bind ctrl-shift-v to paste-nodes-retaining-clones. Perhaps the binding for 
> ctrl-shift-v should change in leoSettings.leo.
>
>
> The work on this project has not been in vain. We all now understand more 
> deeply how Leo's paste-node commands affect gnxs.
>
>
> Please comment. I'll leave #3429 
>  open while we 
> continue our discussion.
>
>
> 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/809cc8a9-077e-4238-8084-683ee6e82963n%40googlegroups.com.

Aha: no need for a new paste command

[Edward K. Ream]

 

#3429  suggests that 
Leo's paste-node command should retain gnxs if doing so would create no gnx 
clashes in the pasted node.


Thomas, Félix and I have been debating what *anyGnxClashes *should check. 
Should it check the entire pasted tree or only its root? Depending on the 
answer, the paste-node will act like Leo's *legacy *paste-node or 
paste-node-retaining-clones commands.


*Aha!* The contents of the target outline don't matter! *What matters is 
the user's intention*.


Thomas uses cut-node/pastes-node mostly to move outlines. For him, 
paste-node-retaining-clones is likely the best binding for ctrl-shift-v.


But I typically use copy-node/paste-node to cherry-pick outlines from other 
branches. For me, paste-node is the best binding.


*Summary*


When using paste-node, the user won't know what anyGnxClashes will return. 
That can't be good!


*Aha*: it *shouldn't matter* what nodes are in the target outline. What 
matters is whether the user *wants *to regain gnxs!


Users who regularly use copy-node/paste to move nodes may find it best to 
bind ctrl-shift-v to paste-nodes-retaining-clones. Perhaps the binding for 
ctrl-shift-v should change in leoSettings.leo.


The work on this project has not been in vain. We all now understand more 
deeply how Leo's paste-node commands affect gnxs.


Please comment. I'll leave #3429 
 open while we 
continue our discussion.


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/8061f9f5-b6b4-42ac-aaec-dbc89c68063en%40googlegroups.com.