Re: Why gnx-based unls are important

2023-07-06 Thread Thomas Passin 
I have *@string unl-status-kind = legacy *set in myLeoSettings.leo, and the 
status bar does show the path-based UNL.  I added a setting *@string 
unl-status-kind = gnx* to my workbook, restarted Leo, and for that outline, 
I see gnx-style addresses in the status bar.

Leo 6.7.4-devel, devel branch, build 947ea935f5
2023-07-06 08:01:34 -0500
Python 3.11.4, PyQt version 6.4.3
Windows 10 AMD64 (build 10.0.19045) SP0

On Thursday, July 6, 2023 at 9:06:47 AM UTC-4 lewis wrote:

> No, the local file does not have @string unl-status-kind = legacy
> Only myLeoSettings.leo has @string unl-status-kind = gnx 
>
> Strange. Both my desktop and laptop have this behaviour. I'll keep 
> investigating.
>
> On Thursday, July 6, 2023 at 10:53:33 PM UTC+10 Edward K. Ream wrote:
>
>> On Thu, Jul 6, 2023 at 4:40 AM lewis  wrote:
>>
>>> In myLeoSettings.leo I have:
>>> @string unl-status-kind = gnx
>>>
>>> However the status bar still shows legacy format, it does not show links 
>>> in the gnx format:
>>> unl:gnx//G:/My Drive/editor/workbook.leo#lewis.20170803232020.1
>>>
>>> Do I need to add another setting?
>>>
>>
>> Works for me in devel.
>>
>> Does your local .leo file define @string unl-status-kind = legacy ?
>>
>> 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/ee1bd2d6-0c34-4634-9ee5-1d6de2b7db35n%40googlegroups.com.

Re: Why gnx-based unls are important

2023-07-06 Thread Thomas Passin 

On Thursday, July 6, 2023 at 8:56:59 AM UTC-4 Edward K. Ream wrote:

On Wed, Jul 5, 2023 at 10:53 PM Thomas Passin  wrote:

This is why I am sticking with the legacy format for the status bar.


What do you mean by "This"?


What @iamap wrote:
"Btw, I do believe gnx-based unls is important, but the current display 
format lack some readability. 
Could it possible to add some readable path string to the end of the unls? 
just for human?

unl:gnx:///Users/mac/.leo/workbook.leo#mac.20230706111222.1

could be better:

unl:gnx:///Users/mac/.leo/workbook.leo#mac.20230706111222.1
*?2023-07-06/leo-note"* 

-- 
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/3acb9bd0-e260-49c8-8c46-9791b08a20c0n%40googlegroups.com.

Re: "Unbreakable UNLs" Can Break Under A Common Scenario

2023-07-06 Thread Thomas Passin 
The gnx change  may be expected, but as a user if I cut a node and paste it 
somewhere else, in my mind it's the *same* node and an "unbreakable" UNL 
should take me to that same node afterwards.  In my mind there should be no 
difference between moving a node using move commands (like CTRL-D) and 
moving it by cut-paste.  

I would say that a user who has not thought about, or maybe not even 
learned about, gnx's would not expect a unl to break when he did a 
cut-paste on a node.  

On Thursday, July 6, 2023 at 8:49:11 AM UTC-4 Edward K. Ream wrote:

> On Thu, Jul 6, 2023 at 7:42 AM Thomas Passin  wrote:
>
>> Here's what I tried in my workbook:
>>
>> 1. Create a node for testing.
>> 2. Copy its gnx to clipboard using a tiny script. *
>> 3. Paste that gnx into the node's body for future reference.
>> 4. Cut the node using the Outline/cut-node item.
>> 5. Paste the node somewhere else in the same outline.
>> 6. Copy the node's gnx to the clipboard.
>> 7. Paste the gnx into the node's body.
>> 8. Observe the 2nd gnx is not the same as the first.
>>
>
> As expected.
>
> 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/8172c852-5cfd-465d-ab59-e331d5493baen%40googlegroups.com.

Re: "Unbreakable UNLs" Can Break Under A Common Scenario

2023-07-06 Thread Thomas Passin 
Here's what I tried in my workbook:

1. Create a node for testing.
2. Copy its gnx to clipboard using a tiny script. *
3. Paste that gnx into the node's body for future reference.
4. Cut the node using the Outline/cut-node item.
5. Paste the node somewhere else in the same outline.
6. Copy the node's gnx to the clipboard.
7. Paste the gnx into the node's body.
8. Observe the 2nd gnx is not the same as the first.

* If you are having the statusbar show the gnx form of the unl, you can of 
course copy that from the clipboard instead of using a little script.

A screenshot of the test node is attached.

On Thursday, July 6, 2023 at 8:31:07 AM UTC-4 Edward K. Ream wrote:

> On Thu, Jul 6, 2023 at 6:40 AM Thomas Passin  wrote:
>
> Maybe a paste of a node should always maintain the gnx unless it would 
>> create a clone.
>>
>
> Hmm. Under what circumstance would a paste-node *not* create a clone?
>
> I sometimes use paste-node to create an independent copy of a node (and 
> its descendants). It's a way of cherry-picking a node from one branch to 
> another:
>
> - Copy and paste a node *N* in branch A to a copy of N, say *N-Copy*.
> - Close Leo, change to branch B.  *Never leave Leo open when changing 
> branches*.
> - Open Leo. Now we're in branch B, but *N-Copy* contains the 
> cherry-picked node from branch A.
> - Copy the body text of nodes from *N-Copy* to N. This changes N's text 
> while preserving N's gnx.
>
> 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/3ae02cba-ac44-4384-a466-5c97d74754c6n%40googlegroups.com.

Re: Proposal: abandon support for .json files and jupyter notebooks.

2023-07-06 Thread Thomas Passin 
I might be more receptive to this idea if we can come up with a way for a 
user to change in and out of the stay-on-top property and the opacity.  It 
won't work as one-size-fits-all, in my experience.

On Thursday, July 6, 2023 at 1:20:46 AM UTC-4 iamap...@gmail.com wrote:

> Btw, I believe making some FW windows always stay on the top and 
> set opacity of windows are also useful.
>
>
> https://stackoverflow.com/questions/19097323/setwindowflagsqtwindowstaysontophint-hides-qt-window
> https://doc.qt.io/qt-6/qwidget.html#windowOpacity-prop
>
> -- 
> --
> Sincerely,
>
> HaveF
>

-- 
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/8b005763-4b2a-4a52-bb20-46b42c3d2676n%40googlegroups.com.

Re: "Unbreakable UNLs" Can Break Under A Common Scenario

2023-07-06 Thread Thomas Passin 
Maybe a paste of a node should always maintain the gnx unless it would 
create a clone.

On Thursday, July 6, 2023 at 12:21:12 AM UTC-4 Thomas Passin wrote:

> I think it's not uncommon to cut a node and paste it somewhere else in the 
> outline.  For example, if I want to move a node from near the top to near 
> the bottom of a long outline, it would be impractical to move it down node 
> by node or to drag it.  I simply cut and paste it.
>
> Trouble is, when you cut a node and paste it, its gnx changes.  To prevent 
> that you would have to remember to paste the node as a clone rather than do 
> a simple paste.  This is asking for trouble. (And it's a weakness of my 
> zettel-kasten system, which is gnx-based).
>
> It's true that legacy path-based UNLs have the same problem.  But at least 
> that's fairly obvious, whereas the new gnx-based UNLs are supposed to be 
> unbreakable.
>
> I don't have a ready solution to offer at this point, but I think it's a 
> real scenario.
>

-- 
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/0eb73578-0f04-45f2-bd03-c8ec2f729d02n%40googlegroups.com.

"Unbreakable UNLs" Can Break Under A Common Scenario

2023-07-05 Thread Thomas Passin 
I think it's not uncommon to cut a node and paste it somewhere else in the 
outline.  For example, if I want to move a node from near the top to near 
the bottom of a long outline, it would be impractical to move it down node 
by node or to drag it.  I simply cut and paste it.

Trouble is, when you cut a node and paste it, its gnx changes.  To prevent 
that you would have to remember to paste the node as a clone rather than do 
a simple paste.  This is asking for trouble. (And it's a weakness of my 
zettel-kasten system, which is gnx-based).

It's true that legacy path-based UNLs have the same problem.  But at least 
that's fairly obvious, whereas the new gnx-based UNLs are supposed to be 
unbreakable.

I don't have a ready solution to offer at this point, but I think it's a 
real scenario.

-- 
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/816baf2d-c7d5-46b8-9378-63d7e83e0b5dn%40googlegroups.com.

Re: Proposal: abandon support for .json files and jupyter notebooks.

2023-07-05 Thread Thomas Passin 

On Wednesday, July 5, 2023 at 11:45:48 PM UTC-4 iamap...@gmail.com wrote:

Thank you for providing a detailed explanation. By the way, I discovered 
the `add-editor` command, although it is not as versatile as the FW.


I always had trouble using an added editor. I was forever switching one to 
the wrong node because I didn't notice it was focused before navigating in 
the tree.  Then I'd be typing into the wrong node.  IIRC, that was one of 
the drivers for me to write the FW plugin.  Also, the added editors only 
apply within one outline, whereas a FW window continues to be visible even 
after you switch to another outline.  Another impetus was that VR3 could be 
used in a free layout separate window but it can't edit its host node, and 
it's not node-locked. 

-- 
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/8e1dc318-3199-4625-9bfc-d7b67c71a696n%40googlegroups.com.

Re: Why gnx-based unls are important

2023-07-05 Thread Thomas Passin 
This is why I am sticking with the legacy format for the status bar.

On Wednesday, July 5, 2023 at 11:27:18 PM UTC-4 iamap...@gmail.com wrote:

> Everything will work provided you define *@data unl-path-prefixes* in 
> your *myLeoSettings.leo* file *on each platform*. These data should 
> define an absolute path (platform-specific) for various .leo files.
>
> Does that means I can set  @data unl-path-prefixes  in my current leo file 
> @settings node to specify a specific x.leo file path?
>
> Btw, I do believe gnx-based unls is important, but the current display 
> format lack some readability. 
> Could it possible to add some readable path string to the end of the unls? 
> just for human?
>
> unl:gnx:///Users/mac/.leo/workbook.leo#mac.20230706111222.1
>
> could be better:
>
> unl:gnx:///Users/mac/.leo/workbook.leo#mac.20230706111222.1
> *?2023-07-06/leo-note*
>
> If we don't support this, we have to describe what the current unl is 
> about...
>  
>

-- 
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/88a9728e-ee17-4e1a-b672-2fb559d8e3ban%40googlegroups.com.

Re: Custom Menus Can Be Very Useful - An Example

2023-07-05 Thread Thomas Passin 
I tried that once and I don't know why I let it slip away.  I'll go back 
and try it again.  After all, I like to put the Windows task bar on the 
left hand side of the screen (Boo to Win11 where apparently you can't do 
that), and I like my browser tabs displayed in a vertical strip.

On Wednesday, July 5, 2023 at 10:58:50 PM UTC-4 iamap...@gmail.com wrote:

> On Thu, Jul 6, 2023 at 10:51 AM Thomas Passin  wrote:
>
>> Just so.  I like some custom buttons, but you can only have so many.
>>
>
> I have a small trick where I can place the iconbar vertically on the side 
> of the leo so that I can fit a little more buttons. XD
>  
>

-- 
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/ff09c4e5-f6db-4423-b83d-d74fbe8f8f25n%40googlegroups.com.

Re: Proposal: abandon support for .json files and jupyter notebooks.

2023-07-05 Thread Thomas Passin 

On Wednesday, July 5, 2023 at 10:30:39 PM UTC-4 iamap...@gmail.com wrote:

There's a large difference between Edward's work flow and mine - not that 
either of us has a single "work flow", I'm sure.  He likes to use clones 
extensively - often extracting them with the cff command, I think.  I tend 
to search using the Nav tab and mark nodes of interest - I have my own key 
bindings to do that, since the bindings of the EditPlus editor were so 
familiar to me from years of pre-Leo use (of course, once you have marked 
some nodes you can clone them all with the *clone-marked-nodes* command).  
Instead of cloning I jump between them with the forward-back arrows and the 
*goto-next-marked* command, which I have bound to F4.  When I want to keep 
looking back at the content of a node, I will usually keep it visible using 
the Freewin plugin (that ability is the main reason I wrote the plugin).


Hi, Thomas, If I'm right, i.e., you mainly use mark, clone to understand 
the problem, 
and Edward mainly aggregates all relevant content through cff and then 
filters it, right?


I haven't used clones very much.  I usually skip around from marked node to 
marked node, plus using the forward/back buttons.
 

Also I looked at the freewin plugin and I don't quite understand why you 
need this? 
Does this plugin look like a panel + viewrender combination? 
Its functionality could be replaced by the powerful 'free layout', wouldn't 
it?
Or is there anything else I missed?


Free layout does not do the same job as  the Freewin plugin.  FW gives you 
a view of a particular node.  No matter where you navigate in the tree, a 
given FW window always shows you the same node (though you can have several 
FW windows open at the same time, each for a different node).  The 
alternate view (the viewrendered-type display) is there mostly so you can 
get a nicely readable rendering of a body written in ReStructuredText, or 
check that your edits to such a node render the way you wanted.

Sometimes I think of a FW window as a kind of index card open next to the 
work in progress.  Also, a FW window is a basic editor that is live on line 
with the underlying node.  So even if you have selected some other node in 
the tree, if you see something that you want to change (in the FW's host 
node), you can just edit it in the FW window and save with CTRL-s as 
usual.  No need to navigate back to that original node to make the change 
and then navigate back.

Suppose you are working with three or four nodes, and you have cloned them 
under an organizing node somewhere,  Since they are close together, you can 
easily move from one to another.  But you can't see more than one at a 
time.  Or instead of (or in addition to) cloning the nodes, you could open 
several of them in FW windows, and arrange those next to Leo's window.  Now 
you could look from one to another without losing sight of the ones you 
navigated away from.  This image 

 shows 
a comparison between some of the prototype FW code to the final plugin 
code.  If you can't see them at the same time it's harder to understand the 
differences. (BTW, FW windows now do syntax coloring; this wasn't in place 
at the time of the screenshot).

Here is the thread in which I introduced the FW plugin.  One of my posts 
 in 
the thread has some screenshots where I tried to show ways I used it.

-- 
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/f8859403-48d5-4236-89e7-9525578a794an%40googlegroups.com.

Re: Custom Menus Can Be Very Useful - An Example

2023-07-05 Thread Thomas Passin 
Just so.  I like some custom buttons, but you can only have so many.

On Wednesday, July 5, 2023 at 10:50:21 PM UTC-4 iamap...@gmail.com wrote:

>
> I create a custom menu for Leo that is located just before the *Help*
>  menu. 
>
> Thanks for sharing.
> It just like grouped buttons. If I really can't stand my numerous buttons 
> I'll consider using menus. XD
>  
>

-- 
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/a2346ee3-e7d9-4beb-b946-173bdbfff421n%40googlegroups.com.

Re: Why gnx-based unls are important

2023-07-05 Thread Thomas Passin 
On Wednesday, July 5, 2023 at 12:57:33 PM UTC-4 jkn wrote:

Apologies for not fully following all of the recent good work here. I meant 
to mention this earlier but just wanted to check this 'platform 
independent' part.

On my Linux box, I get something in the lower 'status bar' like(*)

unl:///home/jkn/path/to/myfile.leo#node-->subnode-->subnode

but when I run on my windows machine, the same file (shared via NextCloud) 
will not be  like this, shurely? What happens if I move my .leo file to a 
different location? Apologies if I am missing something fundamental...


I don't think the concept of operations for the new UNLs has been fully 
worked out yet (Edward may disagree!).  You could think of these old-style 
path-based UNLs to be something like URLs.  They are relative to the server 
(in this case, relative to some file system).  It's an interesting question 
as to what should or would happen for a network file system location.
 

(*) slightly separate point - right click in that area shows 'copy/CTRL+C 
and 'select-all/CTRL+A'. It seems like I have to do CTRL+A followed by 
CTRL+C. I'd suggest that if you have no part of the ... gurl? ... selected, 
then CTRL+C should implicitly select the whole entity before copying


I brought this up in another thread, and the response was that the the 
statusbar code was too tricky to tinker with lightly.  I wanted to have the 
"Copy" item disabled if nothing had been selected.  It's probably a Qt 
thing.
 

-- 
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/9451ee65-f2b0-4964-ad80-ce4ce8a54048n%40googlegroups.com.

Re: Proposal: abandon support for .json files and jupyter notebooks.

2023-07-05 Thread Thomas Passin 
On Wednesday, July 5, 2023 at 12:15:59 PM UTC-4 iamap...@gmail.com wrote:

As you re-organize a file like this, remember that the *extract* minibuffer 
command makes the process much easier.  Add a line to the top of a block 
you want to extract, select the whole block, and the *extract* command will 
pull all those lines into a new node whose headline will be the line you 
added. The new node will be indented in the outline if the selected block 
was indented.


Amazing !!!
I was planning to use `w.getSelectedText().strip()` to reinvent my wheel...


Leo is filled with wonderful conveniences like this.  The only problem is 
to discover them ...
 

Once again, you saved me time, at least half an hour... Thanks!
Hi, Thomas, I believe your daily workflow is an invaluable asset, as well 
as Edward


There's a large difference between Edward's work flow and mine - not that 
either of us has a single "work flow", I'm sure.  He likes to use clones 
extensively - often extracting them with the cff command, I think.  I tend 
to search using the Nav tab and mark nodes of interest - I have my own key 
bindings to do that, since the bindings of the EditPlus editor were so 
familiar to me from years of pre-Leo use (of course, once you have marked 
some nodes you can clone them all with the *clone-marked-nodes* command).  
Instead of cloning I jump between them with the forward-back arrows and the 
*goto-next-marked* command, which I have bound to F4.  When I want to keep 
looking back at the content of a node, I will usually keep it visible using 
the Freewin plugin (that ability is the main reason I wrote the plugin).

Edward has done a lot more study of other code bases than I and that has 
probably got a lot to do with his extensive use of clones compared to me.  
In my case, I'm more likely to be chasing through Leo's code base looking 
for the key method that supports some command or method.  Once I find it, I 
mark it.  I don't want to end up with a lot of cloned nodes just because 
they fit some search pattern but aren't actually what I want.

-- 
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/ceee92f6-80a7-4c37-bfc2-4ff81ca8d9e9n%40googlegroups.com.

Re: Proposal: abandon support for .json files and jupyter notebooks.

2023-07-05 Thread Thomas Passin 
On Wednesday, July 5, 2023 at 8:00:47 AM UTC-4 iamap...@gmail.com wrote:

In most cases reading a .json file into a single file is a good enough 
*start*. You can then convert the node to @clean and reorganize as you like.


OK, it seems like a reasonable solution. Thanks Edward


As you re-organize a file like this, remember that the *extract* minibuffer 
command makes the process much easier.  Add a line to the top of a block 
you want to extract, select the whole block, and the *extract* command will 
pull all those lines into a new node whose headline will be the line you 
added. The new node will be indented in the outline if the selected block 
was indented.

-- 
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/d87fba35-e4f0-4f53-9a20-9414e376be10n%40googlegroups.com.

Re: Discuss: retire two of the three new gnx-related settings?

2023-07-05 Thread Thomas Passin 

On Wednesday, July 5, 2023 at 10:50:36 AM UTC-4 Edward K. Ream wrote:

On Wed, Jul 5, 2023 at 8:48 AM Thomas Passin  wrote:

As for your expression paths = list(reversed([z.h for z in 
p.self_and_parents()])),

 

there is no need  to cast it to a list.


This is the second time you have made this mistaken assertion. reversed is 
a generator:

print(reversed(['a', 'b']))




Aargh!  My mind is still stuck in Python 2! [pounds head on desk].  
Although list.reverse() does not change a list into a generator (although 
it doesn't return anything, just changes the list in place)

-- 
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/2e123ea2-6704-4fc6-9302-93c5f813ef89n%40googlegroups.com.

Re: Custom Menus Can Be Very Useful - An Example

2023-07-05 Thread Thomas Passin 
All right.

I've located the part of Leo's docs that cover menu settings.  It's in the 
LeoDocs outline, at (legacy style)

unl://C:/Tom/git/leo-editor/leo/doc/LeoDocs.leo#Leo's Documentation-->Users 
Guide-->@rst html/customizing.html-->Using settings-->Complex settings 
nodes-->\@menuat

or (new style) 

unl:gnx://C:/Tom/git/leo-editor/leo/doc/LeoDocs.leo#ekr.20090116094356.10

[Of course, replace the outline's location with the right path for your 
system]

Or just search LeoDocs.leo for Complex settings nodes.

Or it's on line at Customizing Leo 
<https://leo-editor.github.io/leo-editor/customizing.html#menus>.

On Wednesday, July 5, 2023 at 6:05:59 AM UTC-4 Edward K. Ream wrote:

> On Tue, Jul 4, 2023 at 10:31 PM Thomas Passin  wrote:
>
>> I create a custom menu for Leo that is located just before the *Help* menu.  
>> It's been so useful that I want to encourage others to create their own.
>
>
> Thanks for this post. Please create a developer info item.
>
> 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/2dcf05aa-dc4b-4433-84ee-2b77c6c6c476n%40googlegroups.com.

Re: New PRs related to gnx-based unls

2023-07-05 Thread Thomas Passin 
As you have probably read by now in my reply to the other post, I don't 
agree at all.

On Wednesday, July 5, 2023 at 8:02:53 AM UTC-4 Edward K. Ream wrote:

> PR #3424  contains 
> *small* tweaks to Leo's code.
>
> Retiring the two settings discussed in this post 
>  
> would be a much bigger change.
>
> If Thomas agrees to the change I'll create a separate 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/03a4ce43-2eb3-4a5d-bf14-416fa7bde06dn%40googlegroups.com.

Re: Discuss: retire two of the three new gnx-related settings?

2023-07-05 Thread Thomas Passin 
I disagree about removing the  *@string unl-status-kind* setting.  I get 
the most value from the status bar when I can see the path of a node.  A 
gnx-based unl tells me nothing useful.  If I want to see if the node is in 
the outline I think it is, I can look at its tab or the title bar of the 
Leo window.  The gnx part is useless for orienting me within an outline.  I 
**really want** to see the path-based expression in there.

If you say, yes, but when we copy from the status bar, we want to get the 
new gnx-based unl, I say fine, but there could be a minibuffer command to 
do that.  In fact, it would be useful to have the context menu for the 
status bar contain separate items for copying either the gnx- or legacy 
path-based UNL of the focused node.

As for your expression paths = list(reversed([z.h for z in 
p.self_and_parents()])), I have two remarks.  First, there is no need  to 
cast it to a list.  [...] returns a list already, as does reversed().  
Second, if that is a serious suggestion then let's have a Leo method to 
return it.  No reason for everybody to roll their own.

On Wednesday, July 5, 2023 at 7:29:35 AM UTC-4 Edward K. Ream wrote:

Don't panic. I'm not going to do anything rash.


Imo, there is no need for these two new settings:


- *@string unl-status-kind = legacy*

- *@bool full-unl-paths = True*


If these settings must remain, their default values should change to:


- *@string unl-status-kind = gnx*

- *@bool full-unl-paths = False*


These settings were essential while working on the big PR. But now *most 
users should use gnx-based unls!*


Furthermore, plugins (including Thomas's plugins) can easily ignore (or 
better, support) gnx-based unls:


*p.get_full_legacy_UNL* writes legacy unls.


Given a gnx-based unl resolved to position p, the following will "recover" 
the path list used in old (path-based) unls:


paths = list(reversed([z.h for z in p.self_and_parents()]))


Heh. A similar line appears in p.get_full_legacy_UNL!


*Summary*


Leonistas should *always* be using gnx-based unls.


Plugins can easily enforce legacy (path-based) unls if they must.


All questions and comments are welcome. I'm not going to do anything rash.


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/19e4f062-0a3b-49da-a7a6-6f8cc3c8f895n%40googlegroups.com.

Custom Menus Can Be Very Useful - An Example

2023-07-04 Thread Thomas Passin 
I create a custom menu for Leo that is located just before the *Help* menu.  
It's been so useful that I want to encourage others to create their own.  
You create one in *myLeoSettings.leo* if you want the menu to be available 
to all outlines, otherwise create in the outline's @settings tree if you 
only want the custom menu to apply to that one outline.  You can have both 
local and global menus at the same time.

I've attached a screen shot of my custom *Local* menu.  All of its items 
run scripts that I wrote, but you could just as easily bind them to 
standard Leo commands.  I chose the menu items with these points in mind:

1. I use the command a lot and want it to be handy to use;
2. I don't use it often but I don't want to forget it either;
3. The display name is easier to understand than the command's real name.
4.  If I ran the command from the minibuffer, I would have to try to 
remember its name with the help of tab completion, and I'd rather not 
bother with that each time I want to use it. The menu item is easier.
5. I'm temporarily using this command a lot;  later I may remove the item.

Of course, if you have too many items in one of these menus, it will start 
getting too long to use conveniently. so there has to be a judgement call 
here.

In the attached image, the last item, *Open Local New User's Guide*, helps 
me to check the work I've been doing on a guide for new Leo users.  When 
that project is done, I'll remove the item.

I won't go into how to set up these custom menus in this post, but ask if 
you need some help to get started.  There's some information in one or 
another of the Leo docs (I forget which), and LeoSettings.leo sets up all 
Leo's standard menus and that can give you an idea of how to proceed.

Using a custom menu is one way to adjust Leo to suit your way of working.  
Give it a try!

-- 
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/7fab99f1-2756-4889-9f0a-82c9526824c5n%40googlegroups.com.

Re: gnx-based unls make the backlink and quickMove plugins obsolete

2023-07-03 Thread Thomas Passin 
This is getting me to think there should be a new method, say 
c.getCrossfileUnl(p), that returns a tuple (file, gnx).  The caller can 
then assemble the two components into a cross-outline UNL if desired, or 
just use the gnx part.  There would be no need for a caller to root around 
to find the right file and combine it with the gnx, but equally no need to 
split out the file part from the gnx part if that were wanted. Or maybe the 
tuple should be (full_unl, file, gnx).  This new method would not replace 
any existing methods, but would be available to new code going forward.

On Monday, July 3, 2023 at 6:00:32 PM UTC-4 Edward K. Ream wrote:

These plugins create and manage links, including cross-outline links. But 
gnx-based unls can also refer to nodes in other outlines! Most users will 
have no need for either plugin.


Both plugins save link data in uAs. That's an interesting approach! 
However, a script could easily create uAs by searching for gnx-based unls. 
The plugins are way too complicated.


*Summary*


The backlink and quickMove plugins are overly-complex ways of following 
cross-outline links. I do not recommend either plugin. Both plugins now 
reside in the 'Experimental/Obsolete' node in LeoPyRef.leo.


All of your comments are welcome.


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/352616f8-e1da-4d3d-a95a-15127effa48bn%40googlegroups.com.

Enhancement - Dragging outline to desktop icon should open in same Leo session

2023-07-03 Thread Thomas Passin 
Some people launch Leo from a desktop icon.  If you have such an icon and 
drag'n'drop an outline on it, the outline will open in a new Leo session.  
Drag another outline, get yet another Leo session.

Some programs (e.g., Notepad++ on Windows) will open dropped files in the 
same open session.  I'd prefer Leo to operate that way.  I don't know, 
programming-wise, how it's done.  I presume there's a way to search through 
the running processes to find Leo if it's there.  In Windows, the task 
manager will list a Leo session as a subordinate to a Python session, so it 
must be feasible somehow.

However, I wouldn't want Leo to operate entirely as a singleton program.  I 
find many situations where I want to be able to open a second Leo window, 
and I wouldn't like to give up that ability.  In those cases, though, I'm 
almost always launching the new Leo session from the console since I want 
to use different command-line parameters.

Terry Brown has some scripts in leo-editor-contrib in which he runs a 
leoserver server,  and clients that send code to Leo via the server to do 
things like import  a file for edit.  I'm wondering if some of that 
capability can be gotten in the way I'm describing instead, without needing 
to run a server.

-- 
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/2b0c3ee5-b9c5-4c41-895b-4f387163630cn%40googlegroups.com.

Re: Debate: always save session data?

2023-07-03 Thread Thomas Passin 

On Monday, July 3, 2023 at 10:57:02 AM UTC-4 Edward K. Ream wrote:

I'm going to shorten *--always-write-session-data* to *--write-session*.


Remember to change  *-a* to *-w *(it's the kind of thing I would forget :-) 
).

-- 
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/544762fc-cd05-43cc-ada0-6b8afea4b923n%40googlegroups.com.

Re: Debate: always save session data?

2023-07-03 Thread Thomas Passin 
I just tested the new code for *--always-write-session-data*, and it worked 
as expected:

1. Open Leo and load several outlines;
2. Close Leo and re-open with *.leo\workbook.leo* on the command line;
3. Close and re-open Leo without an outline on the command line.
4. Observe that the several outlines get loaded.
5.  Close Leo and re-open with *-a* and *.leo\workbook.leo* on the command 
line;
6.  Close and re-open Leo without an outline on the command line.;
7. Observe that only the workbook loads.  This shows that leo.session was 
created.

On Monday, July 3, 2023 at 7:47:38 AM UTC-4 Edward K. Ream wrote:

> On Monday, July 3, 2023 at 6:34:16 AM UTC-5 Edward K. Ream wrote:
>
> > A command line is out of the question.
> ...
> > So we must choose *now* how Leo will work for *everyone.* It's time to 
> resolve this question!
>
> It's funny how writing changes my mind.
>
> *Aha!* The only way to resolve this question is to add the 
> *--always-write-session-data* command-line option.
>
> Debate canceled!
>
> 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/e46631d2-9509-4729-b603-24d82558c5b6n%40googlegroups.com.

Re: Discuss: Remove all session commands?

2023-07-02 Thread Thomas Passin 
I'm not sure we are disagreeing here, and maybe I don't understand the 
state of the code.  I'm saying that if the other commands are in there and 
working, might as well leave them in.  That wouldn't be featuritis since no 
features would be added.   I suppose you could call it "conservation of 
features".

On Sunday, July 2, 2023 at 4:43:19 PM UTC-4 Edward K. Ream wrote:

> On Sunday, July 2, 2023 at 12:22:57 PM UTC-5 Edward K. Ream wrote:
>
> >>Someone may be using [the session commands], someone who isn't following 
> this discussion.
>
> > That's always a danger. The compromise: encourage Félix not to 
> transliterate them :-)
>
> Imagine that the session commands disappear and someone is all hot and 
> bothered about that. Won't they be happy enough to learn that Leo's 
> sessions no work? I see no real reason not to reduce featuritis in this 
> case.
>
> 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/9a43715f-bc7c-4965-bf5b-310391ab76b7n%40googlegroups.com.

Re: Discuss: Remove all session commands?

2023-07-02 Thread Thomas Passin 

On Sunday, July 2, 2023 at 10:09:56 AM UTC-4 Edward K. Ream wrote:

Leo's now requires only two methods from leoSessions.py: *SM.save_snapshot*
 and *SM.load_snapshot*. These two methods read and write json data to 
*~/.leo/session.leo*. Issue #3409 
 suggests writing 
session data to Leo's global cache instead.


I am wondering: is there any reason to retain any of the commands defined 
in leoSessions.py? I think not.


Imo, leoSessions.py should contain only load_snapshot and save_snapshot. 
What do you say?


I agree that going forward, probably only those two are needed.  But if the 
existing commands still work, why remove them?  Someone may be using them, 
someone who isn't following this discussion.

-- 
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/1ec35faa-41a0-417c-b1b6-03566b74e88an%40googlegroups.com.

Re: PR3215 UNL Not Found By CTRL-Click

2023-07-01 Thread Thomas Passin 
All right, let's put it on the back burner for after the next release.  
I'll create a reminder issue for it.

On Saturday, July 1, 2023 at 5:22:42 AM UTC-4 Edward K. Ream wrote:

> On Fri, Jun 30, 2023 at 9:08 PM Thomas Passin  wrote:
>
> Just one thing ... when a CTRL-Click on a UNL navigates to its target, the 
>> focused node in the tree, which is the correct one, is not always visible 
>> in the window.  In my test, I had to scroll the tree to find it.
>>
>
> I've spent about an hour looking into this.
>
> c.redraw(p) calls *LeoQtTree.full_redraw(p)*, which ensures that p is 
> visible via a call to *QTreeWidget.setCurrentItem*.
>
> I have no idea why this doesn't work for ctrl-clicks.
>
> Any change to full_redraw would require careful testing, so this would 
> have to be a separate issue and 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/9c5d8ac9-40c4-48c7-a299-b1bb15f8fb24n%40googlegroups.com.

Re: how to get all the content of the body?

2023-06-30 Thread Thomas Passin 

On Friday, June 30, 2023 at 10:17:35 PM UTC-4 Thomas Passin wrote:

I tested the script with the latest revision of the PR3215 branch that has 
all the UNL/GNX changes.  It still works, Glory Hallelujah!

On Wednesday, June 28, 2023 at 10:14:50 AM UTC-4 Edward K. Ream wrote:

On Wed, Jun 28, 2023 at 8:09 AM HaveF HaveF  wrote:

> Super useful function! It works! You save my day, Thomas!


Hmm, I must have posted that script in a different thread.  Here's the one 
I'm talking about:

UNL = 'unl://C:/Tom/git/leo-editor/leo/core/LeoPyRef.leo#Code-->Core 
classes-->@file leoGlobals.py-->g.Urls & UNLs-->g.handleUnl'

c0, p0 = c, c.p
c2 = g.handleUnl(UNL, c)
content = c2.p.b  # < here is the content of the UNL's body

if c2 is not c0:
g.app.selectLeoWindow(c0)

c0.selectPosition(p0)
print(content[:100])  # To verify we got the right text

-- 
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/b307f3de-e8e8-412a-b33c-6587453e9f3fn%40googlegroups.com.

Re: how to get all the content of the body?

2023-06-30 Thread Thomas Passin 
I tested the script with the latest revision of the PR3215 branch that has 
all the UNL/GNX changes.  It still works, Glory Hallelujah!

On Wednesday, June 28, 2023 at 10:14:50 AM UTC-4 Edward K. Ream wrote:

> On Wed, Jun 28, 2023 at 8:09 AM HaveF HaveF  wrote:
>
> > Super useful function! It works! You save my day, Thomas!
>
> Thanks, Thomas, for your 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/08099399-4bfe-406f-9023-0715193c0bden%40googlegroups.com.

Re: PR3215 UNL Not Found By CTRL-Click

2023-06-30 Thread Thomas Passin 
All right, after merging the latest rev, the outlines open correctly on 
restart, and there is no message about the missing set-rep-dir.cmd file.  I 
went back and checked that problematic UNL and it still is handled 
correctly.

Just one thing ... when a CTRL-Click on a UNL navigates to its target, the 
focused node in the tree, which is the correct one, is not always visible 
in the window.  In my test, I had to scroll the tree to find it.

On Friday, June 30, 2023 at 7:53:17 PM UTC-4 Edward K. Ream wrote:

> 1. After merging the new rev and re-launching Leo, the previously-open 
>>> outlines were not opened, except for the workbook;
>>> 2. I got this (minor) message: not found: 
>>> C:/Tom/git/leo-editor/leo/scripts/set-repo-dir.cmd
>>>
>>
>> I'm seeing something similar, repeatedly.  I'm on it.
>>
>
> Rev 18839a6f0 
> 
>  
> fixes multiple problems, adds important comments and improves a docstring.
>
> All my tests pass.  What about 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/dab20a7d-bec3-4c61-a187-1f8f01caf8bbn%40googlegroups.com.

Re: PR3215 UNL Not Found By CTRL-Click

2023-06-30 Thread Thomas Passin 
It did fix it. 

But two more problems:

1. After merging the new rev and re-launching Leo, the previously-open 
outlines were not opened, except for the workbook;
2. I got this (minor) message: not found: 
C:/Tom/git/leo-editor/leo/scripts/set-repo-dir.cmd

On Friday, June 30, 2023 at 2:43:31 PM UTC-4 Edward K. Ream wrote:

> On Fri, Jun 30, 2023 at 1:25 PM Thomas Passin  wrote:
>
>> Testing the PR3215 branch, I stumbled onto this path-based UNL that Leo 
>> cannot find using a CTRL-click in a different outline.  I copied this UNL 
>> right from the status bar:
>
>
> Thanks for your testing!
>
> I may have found and fixed this bug a few minutes ago.
>
> As of rev c6dc267 
> <https://github.com/leo-editor/leo-editor/pull/3215/commits/c6dc2677fca6a060aae657562de0464c25340a2b>,
>  
> the test cases in test.leo now work for me.
>
> Did this rev fix your problem?
>
> 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/81687547-4c0d-414d-b992-e4f53a9e06c0n%40googlegroups.com.

Re: Transliterate mypy into rust? Using ChatGPT??

2023-06-30 Thread Thomas Passin 
I'd try for Julia, myself.  It's much more like Python, and reputedly very 
fast.  I think the program is too large to be easy to find all the things 
the ChatGPT would get plausible but wrong ...

On Friday, June 30, 2023 at 3:12:08 PM UTC-4 Edward K. Ream wrote:

> I've just asked this question 
>  of the mypy devs.
>
> Any comments? :-)
>
> 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/f3de19bd-8e2e-4dfe-9fad-eb2379be9901n%40googlegroups.com.

PR3215 UNL Not Found By CTRL-Click

2023-06-30 Thread Thomas Passin 
Testing the PR3215 branch, I stumbled onto this path-based UNL that Leo 
cannot find using a CTRL-click in a different outline.  I copied this UNL 
right from the status bar:

unl://C:/Tom/git/leo-editor/leo/core/LeoPyRef.leo#Code-->Gui base 
classes-->@file leoFind.py-->class LeoFind (LeoFind.py)-->LeoFind.Commands 
(immediate execution)-->find.find-def, do_find_def & helpers--><< compute 
the search table >>

The UNL is properly highlighted in the body it was pasted into.  I had 
enabled the setting @string unl-status-kind = legacy.

I wonder if it has to do with the comma embedded in the UNL.

-- 
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/313d6f64-cebb-46f3-9dc3-4fc24ba81fd5n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

2023-06-30 Thread Thomas Passin 

On Friday, June 30, 2023 at 10:01:24 AM UTC-4 Edward K. Ream wrote:

The idea, n*ow fully realized* in PR #3215 
, is this:

1. On exit, Leo *always* saves a list of open outlines (automatic 
session-snapshot-save). 
2. When you open Leo without specifying any files Leo opens the saved list 
of outlines (automatic session-snapshot-load).


I just cycled Leo several time with this morning's update to PR3215.  My 
workbook remains intact, and the other session outlines re-opened.  (Not at 
the first launch:  only the workbook opened, not a surprise, I suppose).  
So that's good.  I suppose when I switch back to devel I'll be at risk of 
losing the workbook, but I do have a backup if that happens. 

-- 
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/b4803cf0-652c-4e43-989d-f55b8d3a6ad5n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

2023-06-30 Thread Thomas Passin 
Sorry, posted by mistake before I was finished.

On Friday, June 30, 2023 at 9:17:54 AM UTC-4 Thomas Passin wrote:

On Friday, June 30, 2023 at 9:00:13 AM UTC-4 Edward K. Ream wrote:

On Friday, June 30, 2023 at 7:54:48 AM UTC-5 Thomas wrote:

I think this is exactly what is wanted most of the time, especially if each 
of the session-loaded outlines gets navigated to the focus when Leo was 
last closed.

The trouble with having the user build and specify the contents of 
specially named sessions is that it's not only a nuisance to do, one 
quickly forgets what each session contains.


Thanks Thomas. That's how I see things too.

 

I actually do use the equivalent of custom temporary sessions sometimes, 
but the way I do it is to use the command line.  I usually keep a Leo 
window open all the time with maybe 5 or 6 outlines open (at a minimum, the 
workbook, my bookmarks manager, and whatever outline I want to work with).  
Sometimes I launch another copy with one or two outlines specified on the 
command line.  Those command lines, in a second console, serve as de facto 
sessions.  They are easy to bring back via the command line history, and I 
can have several.  As long as the first instance of Leo stays open until 
after those other ones are closed, then the session having the first Leo 
instance's outlines will get reloaded the next time I start Leo.


I use a different theme for the second Leo window so I can tell them apart 
without needing to guess. 

This has been working well for me.  

-- 
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/ef6091b0-2b3d-4767-89cb-f5b8f966a40fn%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

2023-06-30 Thread Thomas Passin 

On Friday, June 30, 2023 at 9:00:13 AM UTC-4 Edward K. Ream wrote:

On Friday, June 30, 2023 at 7:54:48 AM UTC-5 Thomas wrote:

I think this is exactly what is wanted most of the time, especially if each 
of the session-loaded outlines gets navigated to the focus when Leo was 
last closed.

The trouble with having the user build and specify the contents of 
specially named sessions is that it's not only a nuisance to do, one 
quickly forgets what each session contains.


Thanks Thomas. That's how I see things too.


I actually do use the equivalent of custom temporary sessions sometimes, 
but the way I do it is to use the command line.  I usually keep Leo open

-- 
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/2cf88d66-0aa8-4df5-a8b0-2a408c0be6ffn%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

2023-06-30 Thread Thomas Passin 

On Friday, June 30, 2023 at 8:41:08 AM UTC-4 Edward K. Ream wrote:

1. On exit, Leo *always* saves a list of open outlines (automatic 
session-snapshot-save).
2. When you open Leo without specifying any files Leo opens the saved list 
of outlines (automatic session-snapshot-load).


I think this is exactly what is wanted most of the time, especially if each 
of the session-loaded outlines gets navigated to the focus when Leo was 
last closed.

The trouble with having the user build and specify the contents of 
specially named sessions is that it's not only a nuisance to do, one 
quickly forgets what each session contains.

-- 
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/107316c9-1667-4c47-8ba3-16e05f52dcfcn%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

2023-06-29 Thread Thomas Passin 
I will second this desire.  I really like being able to restart Leo and 
pick up right where I left off.  I think that has been a very positive 
trait of Leo.  In fact, it gives the user - or at least me - a sense that 
Leo is especially well engineered and that user needs have been carefully 
thought about.  OTOH, leosession only captured the state of the outlines 
when Leo exits, but not (I think) when an outline is closed and then 
reopened in a later Leo session.  That would be valuable.  Why couldn't the 
outline itself store that data when it's closed?  It could be a backwards 
compatible change to the outline's file format.

On Thursday, June 29, 2023 at 8:39:50 PM UTC-4 gates...@gmail.com wrote:

> I would argue that Edward’s solution of ‘just list the files you want to 
> open in a script’ to totally not capture the essence of the session.  The 
> whole point of sessions to me is to keep the flow of what I was doing last. 
>  It’s more than a set of static leo files.  It’s the set of leo files I was 
> working on *last* that’s important, not whatever ones I hardcode into a 
> script.  I use Leo for dozens of reasons, which fluctuate all the time. 
>  I’m going to seriously lose a lot of joy if I have to constantly hunt down 
> which files I was working on last.  Yes, the recent files list helps, but 
> it’s still a lot of unnecessary end-user friction to have to manually open 
> them all up on each start up.
>
> Just my $0.02.
>
> Jake
>
> On Jun 29, 2023, at 8:22 PM, Mike Hodson  wrote:
>
> 
>
> Out of curiosity why is the function of a session considered obsolete? 
>
> This is what I have needed forever, a proper reloading session that 
> automatically saves and does not lose data, regardless if I might have 
> three drafts open that have yet to be saved to disk.
>
> The instant I create a new document, there should be a state file saved on 
> the disk, that keeps the state of the open draft and relates it to an open 
> session.
>
> If my power fails two seconds later I expect to be able to load Leo up and 
> get the exact point where I left off.
>
> I haven't used Leo seriously for the last 5 years because of this lack of 
> functionality.
>
> Mike
>
>
> On Thu, Jun 29, 2023, 16:06 Edward K. Ream  wrote:
>
>> Leo no longer supports --session-restore and --session-save. 
>> LM.scanOptions lists them as obsolete.
>>
>>
>> But the *SessionManager* class still exists. *SM.load_session* is the 
>> culprit behind #3404 
>> . It would be 
>> straightforward to fix this method, but I shall retire the entire class 
>> instead.
>>
>>
>> The SessionManager supports six *session-** commands. The commands allow 
>> you to specify a set of files to open at startup. But listing the desired 
>> files (in a shell script or .cmd file) is simple and good.
>>
>>
>> *Summary*
>>
>>
>> The *session-** commands are absurd solutions to a non-existent problem. 
>> This class significantly complicates Leo's startup logic. The entire 
>> SessionManager class must go. Félix take note :-)
>>
>>
>> As a side effect, Leo will no longer write *~/.leo/leo.session*. 
>>
>>
>> Your comments are welcome. Good luck arguing for this class :-)
>>
>>
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/5480a75d-ada7-4bb0-8a4b-b27c8fe5486an%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> 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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/leo-editor/CAN%2B%2B4hFrZhEmhKD14q7hXufSTjJ95Q9QH-uESxcJgD0TmnPUeg%40mail.gmail.com
>  
> 
> .
>
>

-- 
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/9050c9bb-3922-4710-9ab1-dfd4860c68b5n%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

2023-06-29 Thread Thomas Passin 
Even though I dislike PRs that are very complicated and try to do too many 
things, I have to agree in this case.

On Thursday, June 29, 2023 at 5:37:32 PM UTC-4 Edward K. Ream wrote:

> On Thursday, June 29, 2023 at 3:43:22 AM UTC-5 Edward K. Ream wrote:
>
> > See #3404 . The 
> first comment of the issue discusses the failure and how to fix it.
> > PR #3215  may as 
> well clean up the mess.
> >> On second thought, a new PR will make testing easier...
>
> My first thought was correct. All work must be done in PR #3215. Only that 
> PR has the new methods.
>
> 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/d5a7ae76-8d10-4fcf-bc4f-37b15c86032dn%40googlegroups.com.

Re: Why does leo asks to restart when a .leo file modification is detected? (instead of asking to reload the file?)

2023-06-29 Thread Thomas Passin 
I've wondered about this, too.  It seems obvious to me that if LeoPyRef has 
been changed outside of the Leo session that Leo should restart.  This 
could happen, e.g., if the user checks out a different branch of leo-editor 
or updates the current branch.  For other outlines, maybe the thinking was 
that any outline might contain some part of Leo's runtime code, but if that 
every was the case it doesn't seem so any more.

On Wednesday, June 28, 2023 at 11:49:08 PM UTC-4 Félix wrote:

> Exactly as per the subject line, I'm wondering why does Leo asks to 
> restart when a .leo file modification is detected? Instead of asking to 
> reload the file?
>
> I feel like I asked this question in the past and I cant remember the 
> reason, ...but I searched this google-group for 'restart' and I couldn't 
> find anything... so i just posted this
>
> Thanks for anyone who can enlighten me about this :)
>
> 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/bfe87353-308b-4a56-ac18-673b979dae08n%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

2023-06-28 Thread Thomas Passin 
I agree, but with a non-reproducible report it's hard to make any 
progress.  In this case I wanted to be able to file a more definite issue, 
but also alert people as soon as possible to back up their workbooks until 
the thing gets resolved.  

I do think that one defensive code change to make is for Leo never to 
replace the workbook - whether or not it can find it - without asking the 
user.  On first use, when the Leo user gets created, that wouldn't apply.

On Wednesday, June 28, 2023 at 3:48:14 PM UTC-4 gates...@gmail.com wrote:

> I'd like to propose that *any* data corruption issue at all in Leo should 
> be reported, regardless of whether the steps to replicate are known.  The 
> last thing an editor should ever do is destroy data.
>
> Jake
>
> On Wed, Jun 28, 2023 at 1:49 PM Thomas Passin  wrote:
>
>>
>> On Wednesday, June 28, 2023 at 11:42:37 AM UTC-4 Edward K. Ream wrote:
>>
>> On Wed, Jun 28, 2023 at 10:27 AM Thomas Passin  wrote:
>>
>> I've done more testing, and the pattern is definitely repeatable.  If I 
>> check out the  ekr-3181-mypy-links branch, the first time I launch Leo 
>> the workbook may not be affected but every time after that it is destroyed 
>> and replaced by the default CheatSheet.  When I change back to the devel 
>> branch, the first launch after that also replaces the workbook, but after 
>> that the workbook is opened without replacement.  Remember, in these trials 
>> after each time the workbook gets replaced, I restore it from backup for 
>> the next launch.
>>
>> The replacement does not happen if I specify the workbook on the command 
>> line.  Clearing the recent files list had no effect on the behavior.  
>> Nether did deleting the .leo\db directory.
>>
>>
>> Thanks for this report.  Please file an issue, if you haven't done so. 
>> This issue will have high priority.
>>
>>
>> Done: #3404 <https://github.com/leo-editor/leo-editor/issues/3404>
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/e337e8c2-ba2f-46c3-9780-0154dc9e5e9en%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/e337e8c2-ba2f-46c3-9780-0154dc9e5e9en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/765c1c72-a22e-44e6-a0e4-3cdc35bd7b5en%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

2023-06-28 Thread Thomas Passin 

On Wednesday, June 28, 2023 at 11:42:37 AM UTC-4 Edward K. Ream wrote:

On Wed, Jun 28, 2023 at 10:27 AM Thomas Passin  wrote:

I've done more testing, and the pattern is definitely repeatable.  If I 
check out the  ekr-3181-mypy-links branch, the first time I launch Leo the 
workbook may not be affected but every time after that it is destroyed and 
replaced by the default CheatSheet.  When I change back to the devel 
branch, the first launch after that also replaces the workbook, but after 
that the workbook is opened without replacement.  Remember, in these trials 
after each time the workbook gets replaced, I restore it from backup for 
the next launch.

The replacement does not happen if I specify the workbook on the command 
line.  Clearing the recent files list had no effect on the behavior.  
Nether did deleting the .leo\db directory.


Thanks for this report.  Please file an issue, if you haven't done so. This 
issue will have high priority.


Done: #3404 <https://github.com/leo-editor/leo-editor/issues/3404>

-- 
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/e337e8c2-ba2f-46c3-9780-0154dc9e5e9en%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

2023-06-28 Thread Thomas Passin 
On Wednesday, June 28, 2023 at 12:52:42 PM UTC-4 jkn wrote:

FWIW, I have a vague feeling that something like this happened to me a few 
months ago. It only occurred the once, and I am not 100% sure what 
happened, but it definitely involved the CheatSheet 'appearing'.

Only mentioning it because this would have been before the recent work.


I did too, but it didn't repeat and I couldn't find a way to induce it.

-- 
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/404dc8c2-ef21-4843-8a31-532df94c3b62n%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

2023-06-28 Thread Thomas Passin 
I've done more testing, and the pattern is definitely repeatable.  If I 
check out the  ekr-3181-mypy-links branch, the first time I launch Leo the 
workbook may not be affected but every time after that it is destroyed and 
replaced by the default CheatSheet.  When I change back to the devel 
branch, the first launch after that also replaces the workbook, but after 
that the workbook is opened without replacement.  Remember, in these trials 
after each time the workbook gets replaced, I restore it from backup for 
the next launch.

The replacement does not happen if I specify the workbook on the command 
line.  Clearing the recent files list had no effect on the behavior.  
Nether did deleting the .leo\db directory.

On Tuesday, June 27, 2023 at 5:55:37 PM UTC-4 Thomas Passin wrote:

> I haven't filed an issue on this yet because I haven't got all the 
> conditions nailed down.  But Leo has been replacing my workbook with the 
> default CheatSheet ... sometimes.  *Please* make sure you have a backup 
> copy until this gets resolved.
>
> I noticed this behavior while I was testing code with the branch 
>
> Leo 6.7.4-devel, ekr-3181-mypy-links branch, build b9a9205ae9
>
> This is the branch with with all the new unl code.  I'm not sure if it can 
> also occur on the devel branch.
>
> The problem is that this behavior seems to happen suddenly.  Once it 
> starts, every time I launch Leo with this command line, the workbook.leo 
> outline gets replaced:
>
> py -m leo.core.runLeo
>
> If I include the name of the outline the outline does not get replaced:
>
> py -m leo.core.runLeo .leo\workbook.leo
>
> When the outline gets replaced, I noticed that the other outlines that 
> were opened previously did not get opened.  This made me think that the 
> database was getting corrupted.  But I deleted the .leo\db directory and 
> the workbook still got deleted.
>
> I think that something the the experimental branch is corrupting some 
> string, maybe of the recent files list.  This prevents Leo from finding the 
> workbook.  So it creates a new one.  I have observed that changing back to 
> the devel branch does not stop this behavior on the first launch, but after 
> I run Leo once in devel and then restore the workbook from backup, after 
> that Leo behaves normally and does not replace the workbook.  When I switch 
> back to the experimental branch, that's when this problem starts happening 
> again.
>
> I suggest that if Leo cannot find the workbook when it wants to open it, 
> it should notify the user that it can't find it and ask if it should create 
> a default workbook.  The user will probably say "no!" since they will know 
> that they want to keep the existing one.
>
> Of course, the problem should be fixed, but this would prevent the loss of 
> the workbook in case of future bugs as well.  I don't know about you, but I 
> have a lot of work in my workbook that I really don't want to lose.
>
> I was saved by Leo's new automatic backup, so I had a workbook.leo.bak 
> file when I first realized realized the problem. (Yes, I do back up the 
> .leo directory, but not recently enough this time).
>

-- 
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/b9edd250-0a69-413c-b286-2254f0a1ed37n%40googlegroups.com.

New Ultra-fast replacement for pylint/flake8

2023-06-28 Thread Thomas Passin 
Ruff  is a new-ish linter program that 
does the job of pylint or flake8 but is 100 times or more faster because it 
is written in Rust.  It might be worth looking at for Leo.  

Here's one of the testimonials:

Nick Schrock, founder of Elementl, co-creator of GraphQL:

Why is Ruff a gamechanger? Primarily because it is nearly 1000x faster. 
Literally. Not a typo. On our largest module (dagster itself, 250k LOC) 
pylint takes about 2.5 minutes, parallelized across 4 cores on my M1. 
Running ruff against our entire codebase takes .4 seconds.

It's pypi-installable so presumably usable without executing an external 
program.

-- 
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/01048dda-737f-45c8-9059-ea3700e0b5e0n%40googlegroups.com.

Re: how to get all the content of the body?

2023-06-28 Thread Thomas Passin 
I think you want the method g.getScript().  Look at its docstring in 
LeoPyRef.leo to see how to use it.

BTW, here is how I found it.  I remembered that Leo scripts get run by 
writing a file called *ScriptFile.py*. So I searched for that using the Nav 
tab.  The first thing that came up was in *executeScriptHelper*, so I 
looked at that hit. Its parent is the command *execute-script*.  That 
seemed promising.  Looking in  *execute-script* , I noticed a line script = 
g.getScript(c, p or c.p, useSelectedText=useSelectedText).  So I searched 
for *getScript,* and that seems to be what you want.

This is typically how I find relevant code in Leo's code base.  Others 
probably have their own ways, and mine is probably not the most "efficient" 
way to go about it.  The Nav tab makes it feasible and convenient. It's a 
brilliant feature.  The plugin's docstring says it was created by Ville M. 
Vainio, and I applaud him for it.
On Wednesday, June 28, 2023 at 1:29:23 AM UTC-4 iamap...@gmail.com wrote:

> Hi, Leo user,
>
> Who knows how to get all the contents of the body?
> What I want is to replace << xxx >> and @others in the body.
>
> I have created a simple function, but it has problems handling child nodes 
> or children of child nodes. I suspect there is a ready-made function, but I 
> can't find it anyway, can anyone tell me about it?
>
> Thanks!
>
> Best,
> HaveF
>

-- 
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/5167ebfd-2cb3-4ab3-b23e-c7bc98bd8d9an%40googlegroups.com.

Heads Up - My Workbook Is Getting Destroyed

2023-06-27 Thread Thomas Passin 
I haven't filed an issue on this yet because I haven't got all the 
conditions nailed down.  But Leo has been replacing my workbook with the 
default CheatSheet ... sometimes.  *Please* make sure you have a backup 
copy until this gets resolved.

I noticed this behavior while I was testing code with the branch 

Leo 6.7.4-devel, ekr-3181-mypy-links branch, build b9a9205ae9

This is the branch with with all the new unl code.  I'm not sure if it can 
also occur on the devel branch.

The problem is that this behavior seems to happen suddenly.  Once it 
starts, every time I launch Leo with this command line, the workbook.leo 
outline gets replaced:

py -m leo.core.runLeo

If I include the name of the outline the outline does not get replaced:

py -m leo.core.runLeo .leo\workbook.leo

When the outline gets replaced, I noticed that the other outlines that were 
opened previously did not get opened.  This made me think that the database 
was getting corrupted.  But I deleted the .leo\db directory and the 
workbook still got deleted.

I think that something the the experimental branch is corrupting some 
string, maybe of the recent files list.  This prevents Leo from finding the 
workbook.  So it creates a new one.  I have observed that changing back to 
the devel branch does not stop this behavior on the first launch, but after 
I run Leo once in devel and then restore the workbook from backup, after 
that Leo behaves normally and does not replace the workbook.  When I switch 
back to the experimental branch, that's when this problem starts happening 
again.

I suggest that if Leo cannot find the workbook when it wants to open it, it 
should notify the user that it can't find it and ask if it should create a 
default workbook.  The user will probably say "no!" since they will know 
that they want to keep the existing one.

Of course, the problem should be fixed, but this would prevent the loss of 
the workbook in case of future bugs as well.  I don't know about you, but I 
have a lot of work in my workbook that I really don't want to lose.

I was saved by Leo's new automatic backup, so I had a workbook.leo.bak file 
when I first realized realized the problem. (Yes, I do back up the .leo 
directory, but not recently enough this time).

-- 
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/bec70551-834a-46cc-90d6-fa1c4d344b73n%40googlegroups.com.

Re: Discuss: option for short file names in unls?

2023-06-27 Thread Thomas Passin 
I have several immediate reactions:

1. It was not long ago that we had a long discussion about whether to keep 
using functions in @path headlines.  The outcome was no, don't include 
them.  Why should it be different here?

2. Existing code in plugins and application-style scripts will break, since 
it will not understand the new format.  It will be much harder to write 
code to process the new format.

3. I'll try to say this in the clearest way, something I've commented on 
before.  This kind of proposal will create something new that is not a UNL 
and not a GNX.  Don't try to pretend that it is.  Call it a "unlx:", 
perhaps.  They should be manipulated by new methods with new names.  Old 
core code can be changed by search-and-replace operations if needed, but 
the existing functionality should be kept as is.  Imagine if URLs were to 
have functional changes like this after 30 years.  The entire WWW would 
break.

4. I'm certainly a fan of having outlines use relative paths so they can be 
moved.  So I do favor addresses and pointers that can be either relative or 
absolute.  But note that the example above, unl://ekr.leo#g.findUNL, will 
still not transfer to anyone else's computer or outline.  It's still 
specific to ekr.leo.

5. Though we normally discourage using clones across outlines, my 
zettelkasten system uses gnxs to cross-link information.  The only way an 
outline like this can be copied is to clone all the nodes so the gnxs will 
be unchanged.  So I oppose any change that would make this not work.  
Adding a file path to a gnx for the purpose of creating a findable address 
(e.g., a new style unl) would be fine with me, but changing the gnxs 
themselves would not.

6. I'm not quite sure what is being proposed under the labels "short" vs 
"long" paths, but rather than needing a new setting to use them I think 
that the method Leo will use to process them should figure it out either 
way, just like so many figure out whether a path is absolute or relative.  
The current UNL handling code has a set of known places it searches if it 
can't resolve a path, and the same could be done here.  In terms of 
programmatically creating UNLs, say if a script wanted to create unl-like 
addresses for all qualifying nodes in a subtree, there could be a 
well-defined algorithm for shortening an absolute path.  This should be in 
a method of its own, not buried as part of the overall handling method.
On Tuesday, June 27, 2023 at 2:43:01 PM UTC-4 Edward K. Ream wrote:

> On Tuesday, June 27, 2023 at 1:34:40 PM UTC-5 Edward K. Ream wrote:
>
> Yet another new setting, *@bool full-unl-paths = True* (with the 
> legacy-compatible default), would choose between the long and short forms.
>
> ... 
>
> This option must *not* affect what p.get_UNL returns.
>
>
> Hmm. gnx-based unls *will* contain file parts, so this option *should *affect 
> what p.get_UNL 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/c5abe344-879e-43b1-9aaa-6acda68cf059n%40googlegroups.com.

Re: About PR #3215: unbreakable unls!

2023-06-26 Thread Thomas Passin 

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

2023-06-26 Thread Thomas Passin 
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

2023-06-26 Thread Thomas Passin 
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.

Re: Code Review, Requirements, and Community Particiation

2023-06-26 Thread Thomas Passin 

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.

Code Review, Requirements, and Community Particiation

2023-06-26 Thread Thomas Passin 
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!

2023-06-26 Thread Thomas Passin 
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!

2023-06-26 Thread Thomas Passin 

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: my excel file is not updated to add new data

2023-06-26 Thread Thomas Passin via Python-list 

On 6/26/2023 1:46 PM, small marcc via Python-list wrote:

pandas.ExcelWriter

import pandas

This code creates the path to the Excel file where the data will be written. It 
checks if the file already exists, and if so, reads the existing data into a 
DataFrame. Otherwise, it creates a new empty DataFrame. Then it concatenates 
the existing data with the new data and writes the result to the Excel file. 
Finally, it displays a message that the backup was successful and closes the 
information window.

I do not understand why it does not work, the new data is not displayed in 
excel when I am in python tkinter, my data in python must be displayed in excel.
I use the following code to write data to an excel file using pandas:

please help meHowever, when I run this code, the new data is not showing in the 
excel file.


Do you meant the modified data is not displayed in a linked Excel 
window, or that the Excel file itself does not get changed?



I don't understand why this isn't working. Can you help me solve this problem?

data = {'Numero du client': [numero_du_client],
 'Prénom': [prenom],
 'Nom': [nom],
 'Adresse': [adresse],
 'Numero de téléphone': [numero_de_tel],
 'Longueur de cour': [longueur_de_cour],
 'Largeur de cour': [largeur_de_cour],
 "Unite(p ou m)":[boutonPieds, boutonMetres] #edit
 "Prix_coutant:[prix_coutant],   #new add  he asks me to define when I 
haven't done for others
 "Prix soumission":[prix_soumission], # new add  he asks me to define when 
I haven't done for others
 "MargeProfit":[marge_profit]} # new dd   he asks me to define when I 
haven't done for others


#my link with live excel valid for any move as long as the script and excel are 
in the same folder


chemin_script = os.path.abspath(__file__)
dossier_script = os.path.dirname(chemin_script)
nom_fichier_excel = "testpython.xlsx"
chemin_fichier_excel = os.path.join(dossier_script, nom_fichier_excel)
  df = pd.DataFrame(data)
 if os.path.exists(chemin_fichier_excel):
  df_existant = pd.read_excel(chemin_fichier_excel)
 else:
  df_existant = pd.DataFrame()
 df_concat = pd.concat([df_existant, df], ignore_index=True)
 df_concat.to_excel(chemin_fichier_excel, index=False)
 with pd.ExcelWriter(path, engine='xlsxwriter') as writer:
  df.to_excel(writer, index=False, sheet_name='Clients')
 print("sauvegarde reussi")
 fenetre_info.destroy()



--
https://mail.python.org/mailman/listinfo/python-list

Re: leojs alpha

2023-06-26 Thread Thomas Passin 


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

2023-06-26 Thread Thomas Passin 

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

2023-06-26 Thread Thomas Passin 

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!

2023-06-26 Thread Thomas Passin 
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: About PR #3215: unbreakable unls!

2023-06-26 Thread Thomas Passin 

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: About PR #3215: unbreakable unls!

2023-06-25 Thread Thomas Passin 
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.  Or recreate the pathlike part of the functionality, 
anyway.


Don't panic. I'll work with you on this.


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 pass p and g as function 
arguments instead of using instance method calls.  That turned out to be 
easy since I used them in only a few places, and in a well-defined way that 
was easy to adapt.  The revised code is working.  So that's a relief.

Next I need to see if I can do the same for the zettelkasten code.

However, I feel strongly that p.get_GNX() should return the position's 
actual gnx string, which is what the name says it does..  There should be 
another method, say p.get_unl_gnx() to return that new unl:gnx: string.  
Let's have these method names reflect what they actually do! I assume that 
p.v.gnx will still be the actual gnx string, is that right?

-- 
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/a3b14cee-e64e-4017-ac6d-aa7e8d0211ddn%40googlegroups.com.

Re: About PR #3215: unbreakable unls!

2023-06-25 Thread Thomas Passin 
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 - that is, p.gnx 
- will now be in a different format. If that has been changed, it will 
break the zettelkasten code too, and destroy all the zettel and 
geneological data I have collected and organized.

"Few scripts are likely to use the existing url/unl methods. It is 
impossible to provide complete compatibility."  It can be done by using new 
names for the new methods, etc., and leaving the old ones in place.  When 
Microsoft bit the bullet and started to support Unicode strings, they 
didn't change the old string methods, they added the "Wide" series of 
strings and string functions.
On Sunday, June 25, 2023 at 3:31:41 PM UTC-4 Edward K. Ream wrote:

> 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 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/4a288bbe-1667-4314-9414-3bd8330d625en%40googlegroups.com.

Re: About PR #3215: unbreakable unls!

2023-06-25 Thread Thomas Passin 
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 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.
>
> *New, unbreakable, unls*
>
> The status line now reports unls of the form: unl:gnx:.
>
> After copying this string to any body text:
> - Leo's syntax coloring code will show this as any other url.
> - Control-clicking this url will take you to the first position of the 
> outline having the given .
>
> These unls won't break unless you delete the original node (including all 
> its clones)!
>
> *Summary*
>
> This PR is a milestone in Leo's history. How did we ever live without 
> unbreakable unl links?
>
> Internally, Leo now uses *only* these new unls. The old unls are gone. 
> This PR should simplify leoJS.
>
> I'll merge this PR into devel in a day or three. I won't wait for a code 
> review. The code involved is too tricky to understand in an hour or five.
>
> I'll take full responsibility for any problems that may arise. We aren't 
> going back.
>
> All comments are welcome. There is plenty of time for tweaks.
>
> 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/47b653be-4cf7-4a2c-8bc3-f7f2076f14f3n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 

On Sunday, June 25, 2023 at 10:20:28 AM UTC-4 iamap...@gmail.com wrote:


c0, p0 = c, c.p
c2 = g.handleUnl(unl, c)
content = c2.p.b  # < here is the content of the UNL's body
c0.selectPosition(p)

Oops, typo!  The last line should read
 
c0.selectPosition(p0)

Hi, Thomas,
It works, thank you!


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)
 

It's a useful snippet, we should write it down. But where should we save 
it? Do you know the right place?
https://github.com/leo-editor/snippets seems like a good place, but it 
doesn't update for a long time.


It needs a check to handle the case c2 is None, which would happen if Leo 
can't find the UNL.

Probably a good place is leo-editor-contrib.  Though it can be hard to find 
things in there.  @Edward has been accepting pull requests there.
 

-- 
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/5540954e-c743-4580-b502-20c9b5e784ban%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 
Markdown won't know what to do with a UNL, so you can't expect navigation 
to work in the rendered page.  Also, remember that if an outline's 
organization gets changed - i.e., you move a node - its UNL won't be 
correct any more.  So you only want to use UNLs like that when you have 
high confidence the outline will be stable.  (Few of my outlines are that 
stable).

On Sunday, June 25, 2023 at 9:10:30 AM UTC-4 iamap...@gmail.com wrote:

> Thanks Thomas, I'll try it later
>
> Another thought: is it a good idea to take UNL as a system level schema?
> I can record somewhere like markdown `[something](unl://xxx)` or even 
> pass parameter to that schema if the unl is a script...  
> `unl://x?para1=leo`
>
> On Sun, Jun 25, 2023 at 9:07 PM Thomas Passin  wrote:
>
>> On Sunday, June 25, 2023 at 9:05:20 AM UTC-4 Thomas Passin wrote:
>>
>> On Sunday, June 25, 2023 at 8:43:25 AM UTC-4 iamap...@gmail.com wrote:
>>
>> For now, my UNL points to a position of the current outline. Could we 
>> have a quick way to get it?
>>
>>
>> Assuming that these commands will continue to work after the PR:
>>
>> c0, p0 = c, c.p
>> c2 = g.handleUnl(unl, c)
>> content = c2.p.b  # < here is the content of the UNL's body
>> c0.selectPosition(p)
>>
>> Oops, typo!  The last line should read
>>  
>> c0.selectPosition(p0)
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "leo-editor" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/leo-editor/_TqPXKhD-rs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> leo-editor+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/246ebac0-0439-4592-91bd-9f40bebd3e23n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/leo-editor/246ebac0-0439-4592-91bd-9f40bebd3e23n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> --
> Sincerely,
>
> HaveF
>

-- 
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/6ef87696-16b6-493a-8bb2-42a3969eb358n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 
On Sunday, June 25, 2023 at 9:05:20 AM UTC-4 Thomas Passin wrote:

On Sunday, June 25, 2023 at 8:43:25 AM UTC-4 iamap...@gmail.com wrote:

For now, my UNL points to a position of the current outline. Could we have 
a quick way to get it?


Assuming that these commands will continue to work after the PR:

c0, p0 = c, c.p
c2 = g.handleUnl(unl, c)
content = c2.p.b  # < here is the content of the UNL's body
c0.selectPosition(p)

Oops, typo!  The last line should read
 
c0.selectPosition(p0)

-- 
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/246ebac0-0439-4592-91bd-9f40bebd3e23n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 


On Sunday, June 25, 2023 at 8:43:25 AM UTC-4 iamap...@gmail.com wrote:

For now, my UNL points to a position of the current outline. Could we have 
a quick way to get it?


Assuming that these commands will continue to work after the PR:

c0, p0 = c, c.p
c2 = g.handleUnl(unl, c)
content = c2.p.b  # < here is the content of the UNL's body
c0.selectPosition(p)

-- 
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/6b861b9d-c1c1-4df7-a155-6685060dc4f7n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 
"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 looks like a situation where we should be adding a new API method, not 
changing how the old one works.

On Sunday, June 25, 2023 at 8:43:25 AM UTC-4 iamap...@gmail.com wrote:

>
>>
>> Do you mean you want a method or function to return the text of the body 
>> of the node addressed by the UNL? In general, the UNL could point to 
>> another outline.  Will you be looking only in the current outline, or any 
>> outline?  And if the latter, do you care if that other outline gets opened 
>> during execution of the function?
>>
> For now, my UNL points to a position of the current outline. Could we have 
> a quick way to get it?
>
>
> Looking forward to hearing  PR #3215 
> . it seems a huge PR
>
> --
> Sincerely,
>
> HaveF
>

-- 
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/8e9e0855-37c8-440f-90d4-6f56a97f3063n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 

On Sunday, June 25, 2023 at 7:59:09 AM UTC-4 iamap...@gmail.com wrote:



Would you explain more fully what you mean by "access the content of..."?  
One way is to CTRL-click on the UNL's string in a body node.  This will 
navigate you to that location, opening the outline if necessary.  It should 
also be easy enough to write a new command that navigates to a UNL that is 
in the clipboard. It just depends on what you mean ...

Hi, Thomas, 

Thanks for your reply. 
I want to get the content of UNL by script, like `p.b` to get the body 
content in the current node.


Do you mean you want a method or function to return the text of the body of 
the node addressed by the UNL? In general, the UNL could point to another 
outline.  Will you be looking only in the current outline, or any outline?  
And if the latter, do you care if that other outline gets opened during 
execution of the function?

-- 
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/0a7c9339-3410-47a1-8485-8dfa3e8c456an%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 


On Sunday, June 25, 2023 at 3:27:38 AM UTC-4 iamap...@gmail.com wrote:

[snip]


2. Is there a simple method to access the content of a specific `unl://` 
node? I found `core/LeoPyRef.leo#Code-->Core classes-->@file 
leoGlobals.py-->g.Urls & UNLs`, but it doesn't seem to provide the right 
function for my needs. With the help of gpt, I can't get the answer. But it 
is interesting 
...maybe we 
need a `getAtNodeFromUNL` function XD


That ChatGPT transcript is entertaining.  It's like a student who has not 
digested its lesson but has to say something in class.  The existing method 
that's most likely to be useful is actually *g.handleUnl()*.  This will 
navigate to the given UNL, opening its outline if needed.

-- 
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/9bdb85b3-ce96-4aa0-81d7-b5e555119da1n%40googlegroups.com.

Re: Leo active file bug and how to get the content of unl

2023-06-25 Thread Thomas Passin 
On Sunday, June 25, 2023 at 3:27:38 AM UTC-4 iamap...@gmail.com wrote:

[snip]
2. Is there a simple method to access the content of a specific `unl://` 
node? I found `core/LeoPyRef.leo#Code-->Core classes-->@file 
leoGlobals.py-->g.Urls & UNLs`, but it doesn't seem to provide the right 
function for my needs. With the help of gpt, I can't get the answer. But it 
is interesting 
...maybe we 
need a `getAtNodeFromUNL` function XD


Would you explain more fully what you mean by "access the content of..."?  
One way is to CTRL-click on the UNL's string in a body node.  This will 
navigate you to that location, opening the outline if necessary.  It should 
also be easy enough to write a new command that navigates to a UNL that is 
in the clipboard. It just depends on what you mean ...

-- 
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/8d9bf68f-173b-4d2b-9079-00d9a0ba704en%40googlegroups.com.

Re: TKinter in Python - advanced notions

2023-06-23 Thread Thomas Passin via Python-list 

On 6/23/2023 4:16 AM, Andreas Heckel via Python-list wrote:

Hi,

Apologies for potentially mis-using this thread. But I have been struggling 
recently making exactly this leap from simple GUI examples to a more elaborate 
MVVM concept. Mainly I have been struggling finding nice example python code 
bases, that allow some understanding to the beginner, which I certainly still 
am, but also show enough complexity to see the concept in action.
Any hints / links to github or similar highly welcome. If the list is not the 
appropriate place, I am happy if you email me directly.

Cheers,
Andreas


-Original Message-
From: Python-list
On Behalf Of Diego Souza via Python-list
Sent: Friday, June 23, 2023 4:14 AM
To: aapost
Cc: python-list
Subject: Re: TKinter in Python - advanced notions

Have you considered improving the architecture itself, not your GUI library
skills?

I recommend you look at the Model View ViewModel (MVVM) concept and
implement something similar (this is largely used in the Android framework
nowadays). This would separate your program logic from the rendering and
visualization. It would also make your program more reactive, decoupled,
and easier to maintain. When you mentioned threads I immediately thought of
this because it is much easier to implement parallel jobs and present
results back in the GUI, as everything becomes reactive. This is overkill
for a small project such as the code you showed, but I recommend it for
larger projects.


As a general comment (and I have not done anything tricky or complex 
with Tk), MVC or the other approaches in a similar vein, though good, 
can lead you into more complexity than you need, because of the extra 
abstractions involved.  Yes, for sure the GUI should not be doing domain 
or business logic. Yes, it's good to keep database access separate from 
the other parts of your program. But you may not need all the classes 
and layers that you think you might.  It all depends on what you need to 
do, of course.


Another useful design thought is to try to keep as much of the GUI logic 
separate from Tk itself as possible.  Basically, you would write a more 
abstract (and simpler) GUI API, and then write an adapter that knows how 
to make Tk do those things.  One advantage is that this approach makes 
it easier to change to another GUI toolkit later (say PyQt, for 
example).  Another is that it helps you avoid getting sucked into too 
many Tk details that aren't needed for the program concept.


Here is a simple (or simple-minded :) ) example:

class AbstractApi:
"""An abstract class for standardizing access to a display widget."""
def __init__(self, parent):
self.parent = parent
self.client = None

def registerClient(self, client):
self.client = client

def loadPanel(self, panel_name, html):
"""Load html into display panel."""
pass

def focusPanel(self, panel_name):
"""Select a named display panel."""
pass

def handleSearchText(self):
pass

def writeStatusBar(self, msg):
pass

def handleLinkClicked(self, uri, source):
"""Handle a link clicked in the "source" display panel."""
pass

These (let us say for the purposes of illustration) are the only things 
you need from the GUI.  You can write a Tk-specific version of this, and 
the rest of your program doesn't need to know that Tk is even involved. 
If you want to change to say GTK, this class is the only thing that 
would need to change.


Even if this approach turns out to be too simple for a really 
complicated UI, the closer you can come to realizing it the better.




On Wed, Jun 21, 2023 at 7:20 PM aapost via Python-list <
python-list@python.org> wrote:


On 6/21/23 09:47, Dan Kolis wrote:

I've write a huge biotech program ( an IDE for synthetic biology ), and

am slowly outgrowing TKINTER.


Has anybody out there merged a little bit of TCL direct calls from

Python 3.X to get more freedom then TKINTER for just some Windows ?


I wish it looked better, but its 'ok'. I believe X11 IO is considerably

superior for serious work the HTML.  I mean 'serious' work. with lots of
multi media windows. I am not talking about fb "Oh ! There is a window it
opened inthe corner !"... trivial functionality.


I don't know if it would help, but you can extend/add tcl/tk packages

I don't remember the full instructions right off, but quickly reverse
engineering my old stuff I think you just need to drop them in
/usr/share/tcltk/ or equivalent.

(I needed to do that to replace the terrible looking default file dialog
for unix/linux with fsdialog.)

then running something like the following from your Tk object

self.eval('package require fsdialog')

(reverse engineering the python tkinter source you can likely find other
ways of doing more tcl direct stuff)

I have not researched if there are some better, more featured
(non-buggy) Text widgets implemented in tcl that can be dropped in, (I
know

Re: expected behavior for removing spaces before lines outputed by an indented '@others'

2023-06-23 Thread Thomas Passin 
Oh, I see.  If it's an external file with sentinels it could be tricky 
because you'd have to unindent the correct block the right amount, 
sentinels and all.  I just succeeded  with an @file tree, but it would be 
easy to mess it up.  I converted the file to an @clean file and when I 
unindented the line in the external file that was in the @others subtree (I 
mean using an external editor), the "@others" line in the Leo outline did 
not get unindented as one would expect.

Tricky!

On Friday, June 23, 2023 at 4:44:36 PM UTC-4 Félix wrote:

> Thank, but the unexpected behavior I tried to verify is when* removing 
> the indentation in the external file itself externally*  (with a file 
> editor of your choice) and then saving it, to have Leo refresh it from file 
> by answering 'yes' to the dialog that appears when you do so.
>
> On Friday, June 23, 2023 at 3:59:07 PM UTC-4 tbp1...@gmail.com wrote:
>
>> My expectation is that all lines in the @others subtree will be 
>> additionally indented by the indentation of the "@others" string.  That's 
>> how I have always used it.  I just tried it out in a little outline similar 
>> to yours, and that's what I saw in the external file.  So if the @others 
>> line is not indented, the @others subtree lines are not either.
>>
>> On Friday, June 23, 2023 at 2:39:46 PM UTC-4 Félix wrote:
>>
>>> In a simple outline with an @clean node containing an indented @others 
>>> such as this: 
>>>
>>> [image: Screenshot from 2023-06-23 14-33-30.png]
>>> Let's say there's a couple lines of text in the 'inside node' body pane. 
>>> The external file will have those lines indented with as much space as 
>>> there are before the @others in the parent node.
>>>
>>> What is the expected behavior when I remove the indentation of the line 
>>> produced by the @others in the external file, and save it as such to be 
>>> picked-up by Leo and have it refresh that outline from file? will the 
>>> @others be unindented? or will the @others stay at its position, and the 
>>> inside node content be empty and with it's now unindented line appear below 
>>> the @others?
>>>
>>> In any case, none of this happens. So i'm wondering what's going on? 
>>> (was it always this way? or is this a new intended/unintended behavior?)
>>>
>>> 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/21a5d1cc-9123-410f-98e4-151ae02a1245n%40googlegroups.com.

Re: expected behavior for removing spaces before lines outputed by an indented '@others'

2023-06-23 Thread Thomas Passin 
My expectation is that all lines in the @others subtree will be 
additionally indented by the indentation of the "@others" string.  That's 
how I have always used it.  I just tried it out in a little outline similar 
to yours, and that's what I saw in the external file.  So if the @others 
line is not indented, the @others subtree lines are not either.

On Friday, June 23, 2023 at 2:39:46 PM UTC-4 Félix wrote:

> In a simple outline with an @clean node containing an indented @others 
> such as this: 
>
> [image: Screenshot from 2023-06-23 14-33-30.png]
> Let's say there's a couple lines of text in the 'inside node' body pane. 
> The external file will have those lines indented with as much space as 
> there are before the @others in the parent node.
>
> What is the expected behavior when I remove the indentation of the line 
> produced by the @others in the external file, and save it as such to be 
> picked-up by Leo and have it refresh that outline from file? will the 
> @others be unindented? or will the @others stay at its position, and the 
> inside node content be empty and with it's now unindented line appear below 
> the @others?
>
> In any case, none of this happens. So i'm wondering what's going on? (was 
> it always this way? or is this a new intended/unintended behavior?)
>
> 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/f452e785-ef4f-43cd-bdbe-c39c0d6e4977n%40googlegroups.com.

Re: ChatGPT Helpful In Translating Tables

2023-06-22 Thread Thomas Passin 
Even copying selected text out of a pdf file can be unpleasant.  Often 
there will be no newlines, so words may run together when they were 
visually separated by a line break.

On Thursday, June 22, 2023 at 8:52:14 AM UTC-4 David Szent-Györgyi wrote:

> On Sunday, June 18, 2023 at 11:06:30 PM UTC-4 tbp1...@gmail.com wrote:
>
> Very thoughtful piece by Jon Udell - Why LLM-assisted table 
> transformation is a big deal 
> 
> .
>
>  
> In my day job, I have to pull useful items out of PDFs  - pictures, text, 
> tables. PDFs often make this difficult - because of password-protected 
> access, and because the information that renders as neatly organized text 
> and tables when printed or displayed in a viewer is not neatly organized - 
> the data in the PDF requires rearrangement. Jon Udell's article mentions 
> this without discussing the specifics of the articles he processes. 
>
> It is true that tools like ChatGPT are trained on text and as such most 
> likely to work on text, but they do not reason about non-text. I would 
> argue that a PDF is non-text, and as such, recreating neatly organized text 
> and tables is error-prone; if we really value the facts in a technical 
> publication, we need to start with suitable source, which probably needs 
> carefully done markup created by experts in the subject matter of the 
> publication. 
>
> I would not trust a complex table produced by ChatGPT, since it is not 
> only not a subject matter expert, it cannot reason as a human being can 
> when making sense of such a document. 
>
> I don't know what to say about the extraordinary domain of software that 
> produces those PDFs. How many of those software applications incorporate 
> features meant to allow exploration of the structure of a document? This 
> sounds to me like the sort of job for which Leo is well-equipped! 
>

-- 
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/acc2979a-b113-4cd1-8b52-283a5aa61e63n%40googlegroups.com.

Re: File system path annotations

2023-06-19 Thread Thomas Passin via Python-list 

On 6/19/2023 10:04 AM, Roel Schroeven via Python-list wrote:

Op 19/06/2023 om 11:44 schreef Peter Slížik:

Thank you, Roel. You've answered all my questions.

> [PEP 519]: ...as that can be represented with typing.Union[str, 
bytes, os.PathLike] easily enough and the hope is users

> will slowly gravitate to path objects only.

I read a lot on Python and, frankly, I don't see this happening. 
People on the Internet keep using /str/ as their path representation 
choice. Presumably, programmers don't feel the need to bother with a 
complex solution if the simplest option works just fine.
I agree, I don't see that happening either. I often find myself using 
str for paths: often simple filenames are all that's needed, and then I 
don't see much point in importing pathlib and wrapping the filenames in 
Path() constructors. I do tend to switch to path objects when I start 
needing to do operations on the paths, though.



If you are writing code that will run on both Windows and Linux/Mac, 
pathlib objects are very useful since the path separators will come out 
right with no extra effort. Also, the syntax for composing a path seems 
very natural (e.g., Path('a') / 'b' / 'c'), so that's a bonus.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Please test PR #3398 in the ekr-fix-test branch

2023-06-19 Thread Thomas Passin 
Various Linuces:

3.11 Manjaro:
leo\unittests\test_importers.py ...s... [  5%]
 warnings summary 

leo/plugins/leo_babel/tests/lib_test.py:118
  /home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== 852 passed, 1 skipped, 1 warning in 8.38s 


3.9 Mint (*Note that pyqt6 is not installed on this VM/Python3.9*):
leo/unittests/test_importers.py ...s [ 
 6%]
leo/unittests/core/test_leoAst.py ..s...s... [ 
40%]
leo/unittests/core/test_leoQt6.py s  [ 
92%]
=== warnings summary 
===
leo/plugins/leo_babel/tests/lib_test.py:118
  /home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
== 849 passed, 4 skipped, 1 warning in 9.46s 
===

3.10 Ubuntu:
leo/unittests/test_importers.py ...s [ 
 6%]
leo/unittests/core/test_leoAst.py ..s... [ 
40%]
=== warnings summary 
===

leo/plugins/leo_babel/tests/lib_test.py:118

  /home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)

class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

== 851 passed, 2 skipped, 1 warning in 10.32s 
==

Interesting how much faster these tests run on the various Linuces compared 
with Windows.

-- 
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/cd241e92-c5f6-48d2-bcdf-479cfaf00aa1n%40googlegroups.com.

Re: Please test PR #3398 in the ekr-fix-test branch

2023-06-19 Thread Thomas Passin 
On Windows 10, py -3.xx pytest:

python 3.11:
leo\unittests\test_importers.py ...s... [  5%]
 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== 852 passed, 1 skipped, 1 warning in 15.03s ===

Python 3.10:
leo\unittests\test_importers.py ...s... [  5%]
leo\unittests\core\test_leoAst.py ..s.. [ 40%]
 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== 851 passed, 2 skipped, 1 warning in 13.50s ===

Python 3.9:
leo\unittests\test_importers.py ...s... [  5%]
leo\unittests\core\test_leoAst.py ..s...s.. [ 40%]
 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== 850 passed, 3 skipped, 1 warning in 20.97s ===

Interesting how 3.10 is faster than 3.9 and 3.11.

On Monday, June 19, 2023 at 6:33:32 AM UTC-4 Edward K. Ream wrote:

> Thanks to those who have tested the recent code.
>
> PR #3398  contains my 
> proposed fixes for several failing unit tests.
>
> I have tested this with various versions of python on both Windows and 
> Ubuntu.
>
> Please check out the ekr-fix-test branch and report any further 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/57bf6e6c-cfd2-424b-9965-7a3d659f37c1n%40googlegroups.com.

ChatGPT Helpful In Translating Tables

2023-06-18 Thread Thomas Passin 
Very thoughtful piece by Jon Udell - Why LLM-assisted table transformation 
is a big deal 

.

-- 
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/69524f8e-4d13-4731-8376-34d6a036cfbcn%40googlegroups.com.

Re: Please test Leo's options code in devel

2023-06-18 Thread Thomas Passin 
Python 3.10 on Ubuntu:

=== warnings summary 
===

leo/plugins/leo_babel/tests/lib_test.py:118

  /home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)

class TestCmdr:



-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

=== short test summary info 


FAILED leo/unittests/core/test_leoAst.py::TestTOG::test_TryStar - 
AssertionError: make_tree failed

FAILED 
leo/unittests/core/test_leoImport.py::TestLeoImport::test_recursive_import 
- AssertionError

= 2 failed, 850 passed, 1 skipped, 1 warning in 11.32s 
=

Leo 6.7.4-devel, tbp-tree branch, build e58396da1b
2023-06-18 18:19:34 -0500
Python 3.10.6, PyQt version 6.3.2
linux

-- 
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/771f844d-c368-4ebe-85fb-bcf3b5672047n%40googlegroups.com.

Re: Please test Leo's options code in devel

2023-06-18 Thread Thomas Passin 
Python 3.9 on Linux Mint:

  === warnings summary 
=== leo/plugins/leo_babel/tests/lib_test.py:118 
/home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py) 
class TestCmdr: -- Docs: 
https://docs.pytest.org/en/stable/how-to/capture-warnings.html 
*=== 
short test summary info * FAILED 
leo/unittests/core/test_leoAst.py::*TestTOG::test_TryStar* - 
AssertionError: make_tree failed FAILED 
leo/unittests/core/test_leoImport.py::*TestLeoImport::test_recursive_import* 
- AssertionError = *2 failed*, 848 passed, 3 skipped, 1 warning 
in 10.39s =

Leo 6.7.4-devel, devel branch, build e58396da1b
2023-06-18 18:19:34 -0500
Python 3.9.17, PyQt version 5.15.2
linux

-- 
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/6cae5d82-ea45-4eec-ad8a-d3ee20beec81n%40googlegroups.com.

Re: Please test Leo's options code in devel

2023-06-18 Thread Thomas Passin 
Python 3.11 on Manjaro Linux:

 warnings summary 

leo/plugins/leo_babel/tests/lib_test.py:118
  /home/tom/git/leo-editor/leo/plugins/leo_babel/tests/lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 short test summary info 
=
FAILED 
leo/unittests/core/test_leoImport.py::TestLeoImport::test_recursive_import 
- AssertionError
== 1 failed, 851 passed, 1 skipped, 1 warning in 8.48s 
===

Leo 6.7.4-devel, devel branch, build e58396da1b
2023-06-18 18:19:34 -0500
Python 3.11.3, PyQt version 6.5.1
linux
On Sunday, June 18, 2023 at 10:09:05 PM UTC-4 Thomas Passin wrote:

> On Windows 10, python 3.11, pytest passes all tests.  python 3.10:
>
>  warnings summary 
> leo\plugins\leo_babel\tests\lib_test.py:118
>   C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
> PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
> has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
> class TestCmdr:
>
> -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
>  short test summary info =
> FAILED leo/unittests/core/test_leoAst.py::TestTOG::test_TryStar - 
> AssertionError: make_tree failed
> == 1 failed, 851 passed, 1 skipped, 1 warning in 14.75s ==
>
> Python 3.9:
>  warnings summary 
> leo\plugins\leo_babel\tests\lib_test.py:118
>   C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
> PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
> has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
> class TestCmdr:
>
> -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
>  short test summary info =
> FAILED leo/unittests/core/test_leoAst.py::TestTOG::test_TryStar - Assert...
> == 1 failed, 850 passed, 2 skipped, 1 warning in 23.93s ==
>
> Build info:
> Leo 6.7.4-devel, devel branch, build e58396da1b
> 2023-06-18 18:19:34 -0500
> Python 3.11.4, PyQt version 6.4.3
> Windows 10 AMD64 (build 10.0.19045) SP0
> On Sunday, June 18, 2023 at 9:20:48 PM UTC-4 Edward K. Ream wrote:
>
>> On Sun, Jun 18, 2023 at 3:12 PM Félix  wrote:
>>
>> Please review PR #3398 
>> <https://github.com/leo-editor/leo-editor/pull/3398>. I've tested it on 
>> ubuntu and windows.
>>
>> 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/cd2a1e6a-ab5c-4a02-b937-54c236cb70f6n%40googlegroups.com.

Re: Please test Leo's options code in devel

2023-06-18 Thread Thomas Passin 
On Windows 10, python 3.11, pytest passes all tests.  python 3.10:

 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 short test summary info =
FAILED leo/unittests/core/test_leoAst.py::TestTOG::test_TryStar - 
AssertionError: make_tree failed
== 1 failed, 851 passed, 1 skipped, 1 warning in 14.75s ==

Python 3.9:
 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 short test summary info =
FAILED leo/unittests/core/test_leoAst.py::TestTOG::test_TryStar - Assert...
== 1 failed, 850 passed, 2 skipped, 1 warning in 23.93s ==

Build info:
Leo 6.7.4-devel, devel branch, build e58396da1b
2023-06-18 18:19:34 -0500
Python 3.11.4, PyQt version 6.4.3
Windows 10 AMD64 (build 10.0.19045) SP0
On Sunday, June 18, 2023 at 9:20:48 PM UTC-4 Edward K. Ream wrote:

> On Sun, Jun 18, 2023 at 3:12 PM Félix  wrote:
>
> Please review PR #3398 
> . I've tested it on 
> ubuntu and windows.
>
> 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/f7138c6f-fa5c-4c78-b733-22d6161900ban%40googlegroups.com.

Re: PR #3397 (screen shots) is ready for review

2023-06-18 Thread Thomas Passin 
Oh, I misunderstood.  I thought you meant that the PR had already been 
merged.  What I'm looking at in the plugins directory must be the old 
version.

On Sunday, June 18, 2023 at 2:06:53 PM UTC-4 Thomas Passin wrote:

> It's in the plugins directory but not in LeoPyRef as yet.  There is also a 
> screen_capture.py plugin ... how do they differ?
>
> On Sunday, June 18, 2023 at 1:59:15 PM UTC-4 Edward K. Ream wrote:
>
>> PR #3397 <https://github.com/leo-editor/leo-editor/pull/3397>:
>>
>> 1. Removes all traces of the --screen-shot command-line option.
>> 2. Adds two new commands when the screenshots.py plugin is enabled:
>>  
>>   - take-local-screen-shot captures Leo's main window.
>>   - take-global -screen-shot captures the entire screen.
>>
>> Both commands print a message, wait 5 seconds, take the shot, and save it 
>> to the user's home directory.
>>
>> 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/07576320-8e28-4842-8e7b-801413d32befn%40googlegroups.com.

Re: PR #3397 (screen shots) is ready for review

2023-06-18 Thread Thomas Passin 
It's in the plugins directory but not in LeoPyRef as yet.  There is also a 
screen_capture.py plugin ... how do they differ?

On Sunday, June 18, 2023 at 1:59:15 PM UTC-4 Edward K. Ream wrote:

> PR #3397 :
>
> 1. Removes all traces of the --screen-shot command-line option.
> 2. Adds two new commands when the screenshots.py plugin is enabled:
>  
>   - take-local-screen-shot captures Leo's main window.
>   - take-global -screen-shot captures the entire screen.
>
> Both commands print a message, wait 5 seconds, take the shot, and save it 
> to the user's home directory.
>
> 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/af603b0a-8b57-4e14-b681-38749c6c3c7dn%40googlegroups.com.

Distutils Will Be Gone From The Standard Library In Python 3.12

2023-06-17 Thread Thomas Passin 
I don't know if Leo uses distutils in any way, but it won't be in the 
standard library  any more.  It has been 
absorbed into *setuptools*, so its features aren't really gone, but how to 
use them will change.

-- 
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/6fca2b5d-90e4-45f9-b59c-b3d976095068n%40googlegroups.com.

Re: Open new window

2023-06-17 Thread Thomas Passin 
On Saturday, June 17, 2023 at 2:16:13 PM UTC-4 Thomas Passin wrote:

I've attached an image file illustrating this (this example was provided by 
@wangzhaohe).


I meant to write "this asciidoc markup  was provided by @wangzhaohe".

-- 
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/72575759-77ae-42dc-b418-620a0d849982n%40googlegroups.com.

Re: PR #3390 (more options work) merged into devel

2023-06-17 Thread Thomas Passin 
Run from the leo-editor directory:
py -m pytest

[snip]
leo\unittests\core\test_leoImport.py:106: AssertionError
 warnings summary 
leo\plugins\leo_babel\tests\lib_test.py:118
  C:\Tom\git\leo-editor\leo\plugins\leo_babel\tests\lib_test.py:118: 
PytestCollectionWarning: cannot collect test class 'TestCmdr' because it 
has a __init__ constructor (from: leo/plugins/leo_babel/tests/lib_test.py)
class TestCmdr:

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 short test summary info =
FAILED 
leo/unittests/core/test_leoImport.py::TestLeoImport::test_recursive_import 
- AssertionError: 'path: ekr-mypy2/mypy' != 'path: mypy'
== 1 failed, 851 passed, 1 skipped, 1 warning in 14.21s ==

Not a surprise since it's looking for a specific directory on @ekr's 
machine.

-- 
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/d985d11d-2499-4b4b-bf01-d07ee0151fcbn%40googlegroups.com.

Re: Open new window

2023-06-17 Thread Thomas Passin 
Yes, but just how depends on what you mean.  For example, you can open a Qt 
window that displays MatPlotLib or Qt graphics.  Or, if within Leo you run 
some MatPlotLib code, the pyplot.plot() command will open a window to 
display the plots.  You can also run code for a system like Bokeh or 
Holoview that opens a browser window to display the graphics.  If you can 
create SVG for the output, you can display the graphics in the browser. 

Or if you can write the graphics data to an image file, you can view it 
with the viewrendered3 plugin.

I could be more specific if you would be more specific about what you want 
to do.

On Saturday, June 17, 2023 at 12:06:52 AM UTC-4 ran...@gmail.com wrote:

> Can I write a script in Leo, which will create a new window in which I can 
> display some graphics ?

-- 
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/f1e3e6b0-1d1e-4892-b412-b4a8c5eb0c8fn%40googlegroups.com.

Re: Enum + new in 3.11

2023-06-16 Thread Thomas Passin via Python-list 

On 6/16/2023 7:37 PM, dn via Python-list wrote:

On 16/06/2023 23.47, Thomas Passin via Python-list wrote:

On 6/16/2023 1:40 AM, dn via Python-list wrote:
Have you figured-out a use for the @enum.member and @enum.nonmember 
decorators (new in Python 3.11)?




mypy is having trouble with 3.11 enums:

"There are 83 open Enum mypy issues at the the time of this writing.

Getting the Enum datatype to work with mypy is becoming impossible as 
I find myself having to use cast() in at least every other line."


(see https://gi


thub.com/python/mypy/issues/12841)


There have also been other changes to enum  in 3.11 - here is a useful 
rundown:


https://www.andy-pearce.com/blog/posts/2023/Jan/whats-new-in-python-311-new-and-improved-modules/#enum

I had no idea



Sorry to hear about mypy. PyCharm has its own mechanism - if there's 
something like mypy underneath, I don't know [which].


TBH I haven't noticed any such difficulties, BUT haven't tried using 
more than a defined sub-class of Enum - and using such as a class. Thus:


class MenuOptions( Enum ):
     """ Legal menu-choices. """
     N = "NewGame"
     L = "LoadGame"
     


if __name__ == "__main__":
     n:MenuOptions = MenuOptions.N
     print( n, type( n ) )
     # MenuOptions.N 

works correctly, but strikes me as pedantry.
(any (mypy) problematic code you'd like me to try (in PyCharm) as a 
comparison? Perhaps off-list - could summarise any pertinent discoveries 
later...)



I tried messing with the enum-members, eg N:str; but realised that 
although this worked/was passed silently, the name of a member is not 
actually a string anyway. So, backed that out.



Had noted the first web.ref but deemed it unimportant (to me - as 
above). The second I had not found, and enjoyed reading (many thanks!).


«I’ll be honest, I struggled to think of concrete cases where this would 
be useful, since I don’t tend to pile additional functionality into my 
enumerations — they’re almost always just bare classes which are members 
of another class or module which provides the related functionality. But 
I think it’s good to broaden your horizons...»


The last being the same view as led me to this point, and the first, the 
motivation for this post! As said, I tend to only use enums in a fairly 
mechanistic fashion.


However, I have been playing-around with his "additional functionality". 
For example, adding the idea of a default-value if an enquiry attempts 
to use a 'key' which is not present (which seems 'natural', but equally 
goes against (my understanding of) the ethos of an enum). Next, (see 
earlier comment about having to invoke the @member-target as a function) 
was the idea that if one is using an enum as a collection of the correct 
choices/responses in a menu (per code snippet), making the member.value 
into a function* attempts to reproduce the idiom of using a dict[ionary] 
to simulate a case/select construct - which combines the idea of an 
API's constants with making a decision as to which functionality should 
be invoked.


* function here (cf "method") because unlikely to locate such 
functionality within the enum. However, am also experimenting with 
classes (cue OOP-mumblings, eg "polymorphism", "inversion", ...)


All the fun of the fair!

BTW when I reach the point of making comparisons, I expect the enum will 
be 'cheaper' in storage; but that the dict-construct will be 'faster' - 
pure speculation(!) Repeating: curious cats, etc...




From reading the references, especially the second one, it seems to me 
that these new features are mostly intended to handle weird cases 
involving subclasses of enums.  I plan to master these features by 
avoiding them - and hope I never need to understand someone else's code 
that uses them.


--
https://mail.python.org/mailman/listinfo/python-list

Re: New argument processing code merged into devel

2023-06-16 Thread Thomas Passin 
One additional idea you might entertain as long as you are thinking about 
argument parsing functions.  Most command line processing functions return 
a string, and it is up to the downstream code to convert it to an int, 
float, whatever.  My own - overly simple, for sure - includes an optional 
default value in its function signature.  The code returns the argument 
already cast to the type of the default value.

One might raise the question of separation of concerns - an argument parser 
doesn't need to know about the argument's types, perhaps - but usually 
there is a default value provided somewhere, and why not put it in the code 
that returns the argument?

On Friday, June 16, 2023 at 3:23:49 PM UTC-4 Edward K. Ream wrote:

> On Friday, June 16, 2023 at 1:46:37 PM UTC-5 Edward K. Ream wrote:
>
> a *stateless *class, say *g.OptionsUtils*, would simply package a set of 
> functions. I am going to experiment with this pattern.
>
>
> Experiments show that just adding four functions to leoGlobals.py is more 
> convenient.
>
> The latest code is in PR #3389 
> .  All comments 
> welcome.
>
> 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/df0f1ae0-faad-47e1-83a6-ddae407fb7dfn%40googlegroups.com.

Re: Enum + new in 3.11

2023-06-16 Thread Thomas Passin via Python-list 

On 6/16/2023 1:40 AM, dn via Python-list wrote:
Have you figured-out a use for the @enum.member and @enum.nonmember 
decorators (new in Python 3.11)?



"What's New" says:
Added the member() and nonmember() decorators, to ensure the decorated 
object is/is not converted to an enum member.


The PSL docs say:
@enum.member
     A decorator for use in enums: its target will become a member.

also:
enum members have names and values (the name of Color.RED is RED, the 
value of Color.BLUE is 3, etc.)


Whereas the "Utilities and Decorators" section is slightly confusing 
because class decorators are mixed with others, so one has to read 
more-carefully.



"Curiosity killed the cat" and other cautionary tales/tails...

Have added the following decorated staticmethod to a basic enum. It is 
indeed recognised as a member of the enum, but its value is the 
method-object. To gain the value the method-object represents 
(property-like behavior) one has to call the method/enum-value as a 
function:-



from enum import Enum, member


class MenuOptions( Enum ):
     """ Legal menu-choices. """
     N = "NewGame"
     L = "LoadGame"
     # ...

     @member
     @staticmethod
     def extra_member()->str:
     return "QuitGame"


def print_demo( enum_chosen:MenuOptions )->None:
     """ Illustrative printing. """
     print( "Name:", enum_chosen, enum_chosen.name )
     if isinstance( enum_chosen, MenuOptions ):
     print( "Value:", enum_chosen.value )


print( MenuOptions.__members__ )
# {'N': , 'L': , 
'extra_member': MenuOptions.extra_member at 0x7f0802128860>)>>}


print_demo( MenuOptions[ "L" ] )
# Name: MenuOptions.L L
# Value: LoadGame

print_demo( MenuOptions.extra_member )
# Name: MenuOptions.extra_member extra_member
# Value: 0x7f0802128860>)>


print( MenuOptions.extra_member.value() )
# QuitGame


Therefore, like an @property decorator applied to a method in a 
custom-class, it could be used to only evaluate some 'expensive' 
computation if/when it is needed. Similarly, it could use the other 
values within the enum in order to present some 'combination'.


Weirdly (given that enums are considered immutable) I imagine that if 
the 'extra_member' were to call some external function with varying 
output, the value could be considered mutable when it is eventually called.


Other?better ideas...


mypy is having trouble with 3.11 enums:

"There are 83 open Enum mypy issues at the the time of this writing.

Getting the Enum datatype to work with mypy is becoming impossible as I 
find myself having to use cast() in at least every other line."


(see https://github.com/python/mypy/issues/12841)

There have also been other changes to enum  in 3.11 - here is a useful 
rundown:


https://www.andy-pearce.com/blog/posts/2023/Jan/whats-new-in-python-311-new-and-improved-modules/#enum

I had no idea

--
https://mail.python.org/mailman/listinfo/python-list

Re: Discuss: don't use argparse to handle command-line arguments

2023-06-15 Thread Thomas Passin 
Just for general interest, here's my little argument parser:

import sys

def getopt (param, default=None):
"""Return a named parameter value from the command line.

The parameter and its value must be of the form

-param value

The parameter string and its following value are removed 
from sys.argv. If the parameter is not present on the command line,
then the value of the variable is not changed, and nothing
is removed from sys.argv. 

Param can be a flag (that is, a boolean will be returned and the
value on the command line following the flag will not be returned
or consumed) if the "default" parameter is omitted or None. 
Typical code for this usage would be:

WANT_HELP = getopt('-h') 
if WANT_HELP:
print(__doc__)
sys.exit(1)

NOTE: this function converts the result type to the type
of "default" - e.g., int(), float(), or bool().

ARGUMENTS
param -- the name of the command line option, including the 
 '-' character if used.
default -- the default value for the parameter.  If omitted,
   the function returns True if the param is present.

RETURNS
the new value of the parameter, or the default value if param
is missing from the command line, or True if param is a flag 
(i.e., "default" is omitted or None).
"""

try:
opt = sys.argv.index(param)
del sys.argv[opt]
if default is not None:
option = type(default)(sys.argv.pop(opt))
else:
option = True # don't consume the next parameter
except ValueError:
option = default # param is not in sys.argv
except IndexError:
msg = '"%s" parameter is missing its required value' % param
raise ValueError(msg)
    return option
On Thursday, June 15, 2023 at 8:50:14 AM UTC-4 Thomas Passin wrote:

> I wrote my own a few years ago.  It was simple to use and understand.  It 
> was too simple, perhaps, but it did what I needed for a range of small 
> programs.  The only thing it doesn't do is to flag unknown options: it 
> ignores them instead.
>
> I say, if you don't need all the complexity of argparse don't use it!
>
> On Thursday, June 15, 2023 at 5:36:55 AM UTC-4 Edward K. Ream wrote:
>
>> On Thursday, June 15, 2023 at 3:36:13 AM UTC-5 Edward K. Ream wrote:
>>
>> I plan to rewrite LM.scanOptions without argparse.
>>
>>
>> Initial work is promising.  *Everything* seems easier w/o argparse!  See 
>> PR #3382 <https://github.com/leo-editor/leo-editor/pull/3382>.
>>
>> 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/806cc6bd-1c1e-4cb9-9cf2-8ffe2eb3cd1bn%40googlegroups.com.

Re: Discuss: don't use argparse to handle command-line arguments

2023-06-15 Thread Thomas Passin 
I wrote my own a few years ago.  It was simple to use and understand.  It 
was too simple, perhaps, but it did what I needed for a range of small 
programs.  The only thing it doesn't do is to flag unknown options: it 
ignores them instead.

I say, if you don't need all the complexity of argparse don't use it!

On Thursday, June 15, 2023 at 5:36:55 AM UTC-4 Edward K. Ream wrote:

> On Thursday, June 15, 2023 at 3:36:13 AM UTC-5 Edward K. Ream wrote:
>
> I plan to rewrite LM.scanOptions without argparse.
>
>
> Initial work is promising.  *Everything* seems easier w/o argparse!  See 
> PR #3382 .
>
> 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/6235e6ed-891c-4676-9827-75e7ffbe0199n%40googlegroups.com.

Re: Improved recursive import in devel. Please update scripts

2023-06-14 Thread Thomas Passin 
On Wednesday, June 14, 2023 at 11:06:01 AM UTC-4 Edward K. Ream wrote:

On Wed, Jun 14, 2023 at 8:06 AM Edward K. Ream  wrote:

On Wednesday, June 14, 2023 at 8:00:08 AM UTC-5 Edward K. Ream wrote:

PR #3363  improves the 
outlines created by scripts that call c.recursiveImport.


One more thing: leo-editor-contrib 
 contains an improved 
mypy.leo 

 
that illustrates the new import scheme. 


And one more thing. Imo it would be best to replace the @path statements in 
headlines with @path statements in body text: @path statements are context 
sensitive. That is, they "accumulate". But this means that cloning and 
moving an @ node will change its effective path.


Yes, pluses and minuses.  With an @path node in the headline, it's 
instantly clear where all the external child files are located.  If the 
@path directive were in the body, this wouldn't be so.   But the point 
about clones is an issue too.  Another matter is how much code is out there 
that looks for @path in the headline.  I don't know, but we should probably 
assume there there is some user code that's not part of the Leo source tree.

-- 
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/95f2683b-d419-4319-bc14-556b89483e27n%40googlegroups.com.

Re: Fwd: AUTO EDITOR DIDN'T WORK

2023-06-13 Thread Thomas Passin via Python-list 

On 6/13/2023 9:43 PM, gene heskett via Python-list wrote:

On 6/13/23 19:10, Thomas Passin via Python-list wrote:

On 6/13/2023 5:32 PM, Alan Gauld via Python-list wrote:

Okay thanks. Meanwhile, I am not tech savvy so I may not say much here.
I followed all the commands as given on the website to install auto
editor standing it on python but after rendering the XML file, I
couldn't open it with my Davinci Resolve 18. I uninstalled and
reinstalled about twice and still no success hence I uninstalled it.


I don't understand when you talk about an "XML file". Auto-editor 
works on video files, or at least .mp4 files, which are not XML files. 
Davinci Resolve does have some ability to interoperate with other 
editors using XML in some way (according to Wikipedia, 
https://en.wikipedia.org/wiki/DaVinci_Resolve) but that's a different 
thing completely.


I also don't know what you mean by "after rendering the XML file" 
since from what I can see auto-edit doesn't render anything.


The simplest thing that auto-editor can do is to cut out long periods 
of dead space, e.g., from an mp4 file.  Their documentation shows how 
to do it.  If it were me, I would run the example command line on a 
sample mp4 file, then see what it looked like in Davinci.  Is that 
what you did? It should be the same video but with some dead space 
removed.


(Note that I'm speaking from a place of no experience with either of 
these software packages; just looking at what auto-edit claims to do).




auto-edit? Never heard of it. xml? I've written hundred of kilobytes of 
it in plain old geany. I didn't know there was a special editor for xml.


Oh, there are, there are - mostly intended for document authoring, I think.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: AUTO EDITOR DIDN'T WORK

2023-06-13 Thread Thomas Passin via Python-list 

On 6/13/2023 5:32 PM, Alan Gauld via Python-list wrote:

Okay thanks. Meanwhile, I am not tech savvy so I may not say much here.
I followed all the commands as given on the website to install auto
editor standing it on python but after rendering the XML file, I
couldn't open it with my Davinci Resolve 18. I uninstalled and
reinstalled about twice and still no success hence I uninstalled it.


I don't understand when you talk about an "XML file". Auto-editor works 
on video files, or at least .mp4 files, which are not XML files. 
Davinci Resolve does have some ability to interoperate with other 
editors using XML in some way (according to Wikipedia, 
https://en.wikipedia.org/wiki/DaVinci_Resolve) but that's a different 
thing completely.


I also don't know what you mean by "after rendering the XML file" since 
from what I can see auto-edit doesn't render anything.


The simplest thing that auto-editor can do is to cut out long periods of 
dead space, e.g., from an mp4 file.  Their documentation shows how to do 
it.  If it were me, I would run the example command line on a sample mp4 
file, then see what it looked like in Davinci.  Is that what you did? 
It should be the same video but with some dead space removed.


(Note that I'm speaking from a place of no experience with either of 
these software packages; just looking at what auto-edit claims to do).




--
https://mail.python.org/mailman/listinfo/python-list

Mint/XFCE Update May Cause Viewrendered3 Plugin to Crash Leo

2023-06-13 Thread Thomas Passin 
It may even crash the whole system.  This is not a bug in VR3, but some 
disconnect between a XFCE change in the OpenGL graphics version and its 
support.  Other projects have had the same problem.  The error message is 
strange, supposedly from vmware:

"vmw_ioctl_command error Cannot allocate memory"

My Linux Mint system is running in VirtualBox, not VMWare, and I think that 
people reporting the same or similar problems with other projects were not 
even running a VM.  I found a solution in this discussion thread 
.  It basically tells 
XFCE to use an earlier version of OpenGL.  It worked for me.

My Manjaro XFCE system does not so far have the problem.

-- 
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/6e48f628-8bc9-4300-b7f9-fdeab8e52ce1n%40googlegroups.com.

Re: AUTO EDITOR DIDN'T WORK

2023-06-12 Thread Thomas Passin via Python-list 

On 6/12/2023 5:26 AM, Real Live FootBall Tv via Python-list wrote:

  I recently Installed and Uninstalled Python, hence the system was trying
to get why I UNINSTALLED python.
I did it because I was going to use it with another application, A VIDEO
EDITING APP, Auto EDITOR but it didn't work for some reasons unknown to me.
Seeing, therefore, that the app didn't work, I thought it was of no use
keeping it occupying space within my system, hence I took it off by
UNINSTALLATION.
If there is anything I can do to make it work, I won't mind getting the
tips from you guys, thanks.



It will be hard to impossible to help without some specific information. 
 Like - what happened to cause you to say "it didn't work", what 
version of what operating system and Python you use, how you installed 
the Auto Editor package, and why you are asking for help after 
uninstalling Python.  You sure won't get it working by uninstalling Python.


The home page for the app is, according to PyPi, 
https://auto-editor.com.  Have you gone through everything there before 
giving up?

--
https://mail.python.org/mailman/listinfo/python-list

<    1   2   3   4   5   6   7   8   9   10   >