Re: Why gnx-based unls are important

[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.

[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.

[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?

[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

[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

[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?

[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

[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

[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

[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?

[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?

[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?

[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?

[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

[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?

[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?

[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

[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

[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??

[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

[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

[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

[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

[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

[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

[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

[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?)

[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

[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&utm_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

[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

[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

[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

[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?

[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

[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?

[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!

[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

[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

[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

[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

[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!

[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!

[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: leojs alpha

[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

[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

[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!

[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!

[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!

[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!

[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!

[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

[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

[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&utm_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

[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

[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

[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

[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

[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

[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: expected behavior for removing spaces before lines outputed by an indented '@others'

[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'

[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

[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: Please test PR #3398 in the ekr-fix-test branch

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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: New argument processing code merged into devel

[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: Discuss: don't use argparse to handle command-line arguments

[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

[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

[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.

Mint/XFCE Update May Cause Viewrendered3 Plugin to Crash Leo

[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: What Was I Working On???

[Thomas Passin]

After I started using this, I found that I sometimes want to capture 
multi-line selections from non-Leo sources, like a browser for example.  So 
I added a modified version of the script that logs the clipboard text to 
the log file.  I added an item for this script to my custom "Local" menu. A 
slight complication is how to indent a multi-line selection so that it's 
easy to read.  This script uses one approach: so far, so good.  Here's the 
script:

"""Write clipboard text to a log file."""
from pathlib import Path
import time
from textwrap import fill

LOG = c.config.getString('notelog') or '~/.leo/temp/notelog.txt'
ACTUALPATH = Path(LOG).expanduser()

text  = g.app.gui.getTextFromClipboard()
if text.strip():
if len(text) > 65:
text = '\n' + fill(text, 70, initial_indent = ' ' * 4, 
subsequent_indent = ' ' * 4)

now = time.time()
localtime = time.strftime("%Y-%m-%d %H:%M", time.localtime(now))
with open(ACTUALPATH, 'a', encoding = 'utf-8') as f:
f.write(f'{localtime}\t{text}\n')
g.es(f'Wrote note to {ACTUALPATH}')

This script also lets you optionally set the location  of the log file with 
the @string setting notelog.
On Wednesday, May 17, 2023 at 10:35:54 AM UTC-4 Thomas Passin wrote:

> Trying it out got me to thinking that it would be handy to be able to log 
> quick little notes.  The following script writes the cursor line on the 
> body to a note log file, whose path can optionally be specified in a 
> setting.  The idea is that you could write a brief one-line note and pop it 
> right into the log file with a time stamp -
>
> """Write cursor line to a log file."""
> from pathlib import Path
> import time
>
> LOG = c.config.getString('notelog') or '~/.leo/temp/notelog.txt'
> ACTUALPATH = Path(LOG).expanduser()
>
> w = c.frame.body.wrapper
> j = w.getInsertPoint()
> s = c.p.b
> beg, end = g.getLine(s, j)
> line = s[beg:end]
>
> if line:
> now = time.time()
> localtime = time.strftime("%Y-%m-%d %H:%M", time.localtime(now))
> with open(ACTUALPATH, 'a', encoding = 'utf-8') as f:
> f.write(f'{localtime}\t{line}\n')
>
> You could do the same thing by keeping a text editor window with the log 
> file open all the time, but if you are working with Leo anyway this would 
> be more convenient.
> On Wednesday, May 17, 2023 at 5:26:25 AM UTC-4 Edward K. Ream wrote:
>
>> On Tuesday, May 16, 2023 at 5:31:04 PM UTC-5 tbp1...@gmail.com wrote:
>>
>> The script registers as an idle time handler.  If a minute has elapsed 
>> since the last check, the script looks to see if the currently focused 
>> outline and node have changed since the last check.  If so, it writes the 
>> time and the node's UNL to the log file.
>>
>>
>> Clever idea. I use the github issue tracker for almost everything I do. 
>> That's usually a good enough reminder :-)
>>
>> 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/b783c12d-78ed-4387-9b3c-6154b9f9111en%40googlegroups.com.

New Mono-spaced Font From Intel

[Thomas Passin]

Intel has open-sourced a new monospaced font family called "IntelOne 
Mono".  It's available via GitHub .  
They say it was developed to be very readable even for people with visual 
handicaps or for developers whose eyes get irritated by long hours staring 
at the screen.

I've only just started trying it out. So far it looks good.  Curly brackets 
look a little odd - I think that's deliberate to make them more readable.

-- 
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/5aff7b1f-1d90-4a08-930c-1153797bf568n%40googlegroups.com.

Re: Another mass update: PR #3367

[Thomas Passin]

That trystar error shows up on my Windows 3.11 machine too:

C:\Tom\git\leo-editor\leo\scripts>test-leo
test-leo
..Missing
 
visitor: TokenOrderGenerator.TryStar
F..s..
==
FAIL: test_visitors_exist 
(leo.unittests.core.test_leoAst.TestTokens.test_visitors_exist)
Ensure that visitors for all ast nodes exist.
--
Traceback (most recent call last):
  File "C:\Tom\git\leo-editor\leo\unittests\core\test_leoAst.py", line 
2745, in test_visitors_exist
assert not errors, msg
AssertionError: 63 node types, 32 op types, 1 errors

--
Ran 848 tests in 9.476s

FAILED (failures=1, skipped=1)

On Saturday, June 10, 2023 at 3:40:20 AM UTC-4 Edward K. Ream wrote:

> On Sat, Jun 10, 2023 at 12:58 AM Viktor Ransmayr  
> wrote:
>
>  I've tested the 'leo-editor:devel' branch in a Fedora 37 VM.
>>
>> Running Leo's unit tests reports two errors:
>>
>
> Thanks for the report. The failing test_visitors_exist test is due to the 
> new `trystar` ast node in Python 3.11. See Leo issue #3368 
> .
>
> The failing test_bug_3270_at_path test is likely due to a problem with 
> the test itself. See Leo issue #3369 
> .
>
> 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/82f8e34f-a23b-4a6b-ac14-d197786736dbn%40googlegroups.com.

Re: Another mass update: PR #3367

[Thomas Passin]

Leo loaded using Python 3.11 on Windows.  So that's good.

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

> PR #3367  imports 
> Callable from collections.abc instead of typing.  typing.Callable is 
> deprecated, but is not presently scheduled for removal. Nevertheless I 
> thought it best to do the replacement.
>
> To my knowledge no further changes to Leo's mypy-related code are needed.
>
> Please report any problems.
>
> 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/46c19cba-f863-448e-8e47-9b15f0894044n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

You might try ```shell too.

On Wednesday, June 7, 2023 at 5:58:24 AM UTC-4 p.os...@datec.at wrote:

> Hm, for now it seems a wrong ```-clause (markdown) being the reason for 
> all the hassle: Replaced all ```bash by ```sh.  I'll see if this holds for 
> clones as well (have to intro them again).
>
> On Friday, June 2, 2023 at 6:05:14 PM UTC+2 tbp1...@gmail.com wrote:
>
>> On Friday, June 2, 2023 at 3:05:51 AM UTC-4 p.os...@datec.at wrote:
>>
>> Again it happended. But now it happoend with vanilla nodes, as I replaced 
>> all clones by copies of the respective nodes. A section is cut off at 
>>
>> ```bash
>>
>> which becomes a node title. This node's body contains then all the sub 
>> nodes of the respective Leo tree.
>>
>>
>> It looks to me that the MD importer is a little confused at this point.  
>> The code that seems to be executing here during the import is
>>
>> elif in_code:
>> if line.startswith("```"):
>> in_code = False
>> lines_dict[top.v].append(line)
>> elif line.startswith("```"):
>> in_code = True
>> lines_dict[top.v].append(line)
>>
>> This *looks* like it should handle the code right, but one would have to 
>> do some checking to see if that is in fact happening as expected.
>>
>>  
>>
>> What I need is an @auto-md that does not read, which for me makes no 
>> sense anyway: The content is in my Leo tree and should just be written into 
>> an MD-file, that will be processed by mkdocs.
>>
>>
>> That's how the *rst3* command works.  The *@rst*  file tree isn't 
>> actually an external file.  The command writes the *@rst* tree to a 
>> file, but that file never gets imported again.  But I don't believe there 
>> is an equivalent command for markdown.  I think there should be.  That may 
>> not be trivial to write because the *@rst3* command looks pretty 
>> complicated to me.
>>
>> OTOH, it probably wouldn't be hard to write a script that writes a 
>> subtree to a file, converting the headlines into the right indent level 
>> headlines.  That's really what you want, isn't 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/1808ebf6-ab41-4759-8b2f-86a85ebedd64n%40googlegroups.com.

Does the Directive @terse Get Used Anywhere?

[Thomas Passin]

The globalDirectiveList includes a directive name of "terse".  A search of 
LeoPyRef doesn't show it being used anywhere.  Is it actually used, and if 
so, for what?

-- 
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/3073e06e-a096-445b-b230-2578f5af2952n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

On Friday, June 2, 2023 at 3:05:51 AM UTC-4 p.os...@datec.at wrote:

Again it happended. But now it happoend with vanilla nodes, as I replaced 
all clones by copies of the respective nodes. A section is cut off at 

```bash

which becomes a node title. This node's body contains then all the sub 
nodes of the respective Leo tree.


It looks to me that the MD importer is a little confused at this point.  
The code that seems to be executing here during the import is

elif in_code:
if line.startswith("```"):
in_code = False
lines_dict[top.v].append(line)
elif line.startswith("```"):
in_code = True
lines_dict[top.v].append(line)

This *looks* like it should handle the code right, but one would have to do 
some checking to see if that is in fact happening as expected.

 

What I need is an @auto-md that does not read, which for me makes no sense 
anyway: The content is in my Leo tree and should just be written into an 
MD-file, that will be processed by mkdocs.


That's how the *rst3* command works.  The *@rst*  file tree isn't actually 
an external file.  The command writes the *@rst* tree to a file, but that 
file never gets imported again.  But I don't believe there is an equivalent 
command for markdown.  I think there should be.  That may not be trivial to 
write because the *@rst3* command looks pretty complicated to me.

OTOH, it probably wouldn't be hard to write a script that writes a subtree 
to a file, converting the headlines into the right indent level headlines.  
That's really what you want, isn't 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/1efa09f2-06e9-490d-bb64-d726cea00ae6n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

If you can, would you please post the offending outline.  Otherwise, if you 
can create a misbehaving example, please post that.

I've not worked with *@auto-xx files* and the only thing I know is that 
when the file's tree is written, headings are inserted for the node 
headlines, indented to match the tree.  Presumably, when the external file 
is read again by Leo it would remove those inserted headlines and use the 
information to re-create the tree. Is something else supposed to happen as 
well? 

On Friday, June 2, 2023 at 3:05:51 AM UTC-4 p.os...@datec.at wrote:

> Again it happended. But now it happoend with vanilla nodes, as I replaced 
> all clones by copies of the respective nodes. A section is cut off at 
>
> ```bash
>
> which becomes a node title. This node's body contains then all the sub 
> nodes of the respective Leo tree.
>
> What I need is an @auto-md that does not read, which for me makes no sense 
> anyway: The content is in my Leo tree and should just be written into an 
> MD-file, that will be processed by mkdocs.
>
> Cheers
> Paul
>
>
> On Friday, May 26, 2023 at 12:58:51 PM UTC+2 p.os...@datec.at wrote:
>
>> Thanks a lot!
>>
>> As for the loss of "cloneness" upon opening the file: I had this as well 
>> and got a hint here in this group (IIRC). Now the clones keep being clones 
>> and my Leo file has a node "@persistence" not added by me, but 
>> automatically somehow.
>>
>>
>>
>> On Wednesday, May 24, 2023 at 4:47:19 PM UTC+2 tbp1...@gmail.com wrote:
>>
>> The GitHub issue is 3355 
>> <https://github.com/leo-editor/leo-editor/issues/3355>.
>>
>> On Wednesday, May 24, 2023 at 10:40:25 AM UTC-4 Thomas Passin wrote:
>>
>> The loss of clones is specific to *@auto-md* trees (although I have not 
>> tested other *@auto-xx* trees):
>>
>> In an outline with both *@clean* and an *@auto-md* trees, when the 
>> outline is closed and re-opened, the clone nodes of the *@clean* tree 
>> remained but the clone nodes of the *@auto-md* tree were no longer 
>> clones.
>>
>> I don't know what the original intention was with respect to *@auto-md 
>> *trees, 
>> but this seems like a serious bug to me.  I'll create an issue for it.
>>
>> On Wednesday, May 24, 2023 at 10:10:34 AM UTC-4 Thomas Passin wrote:
>>
>> I see where the problem is - or at least *a* problem - is, and it's 
>> serious. The problem I see is that when an outline with clones is 
>> re-opened, the clones are no longer clones.  This did not happen when I 
>> created some clones in my Workbook, so there are some conditions yet to be 
>> determined. I'll experiment some more to try to pin it down.  The outline 
>> which showed the problem had both an *@auto-md* and an *@clean* tree.  
>> I'll try outlines with them separately and report back.
>>
>> On Wednesday, May 24, 2023 at 8:22:58 AM UTC-4 Thomas Passin wrote:
>>
>> @Edward recently re-worked some of the importers.  If you can use the 
>> current version of the devel branch (in GitHub) it would be worth trying.  
>> Can you share a tree that suffers from the problem?  Or a minimal version 
>> that does?
>>
>> On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:
>>
>> Sorry, it's Leo 6.6.4 on Arch Linux.
>>
>> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>>
>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>> file.  It is only a tiny, simple file so maybe it's not enough of a test.  
>> Here is what I did:
>>
>> 1. Created an @auto-md file with the following structure:
>>
>> @clean c:\temp\leo\md-test-at-auto-md.md
>> Markdown Test Tree
>> A1
>> A1.1
>> A1.1.1
>> A2
>>
>> 2. I added a line *@others *to the top of the body of the top node.  I 
>> wrote a line or two for most of the nodes.  Then I saved the outline.
>> 3. I added a new top-level node outside the *@auto-md* node.  I cloned 
>> node *A1* into it.
>> 4. In the cloned *A1.1* node, I added a new line.
>> 5. I observed in an external editor that the *@auto-md* file had the 
>> intended change.
>> 6. I closed and reopened the outline.
>> 7.  I did not see any corruption in the outline.
>>
>> Could you write more detail about the *@auto-md* file that ended up with 
>> a corrupted outline, and whether you use an *@others* line in it?  And 
>> is this the only such file that caused a problem?  And also the version of 
>

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

It turns out that this clone issue was discussed several years ago and I 
had completely forgotten about it, maybe because I haven't used *@auto-xxx* 
nodes 
or *@presistence* nodes.   See 
https://groups.google.com/g/leo-editor/c/oKGhRhUVTXA/m/xqUHMJzWAQAJ (thank 
you LewisNeal). But perhaps this is not the issue the OP has been 
encountering? 

On Wednesday, May 24, 2023 at 10:47:19 AM UTC-4 Thomas Passin wrote:

> The GitHub issue is 3355 
> <https://github.com/leo-editor/leo-editor/issues/3355>.
>
> On Wednesday, May 24, 2023 at 10:40:25 AM UTC-4 Thomas Passin wrote:
>
>> The loss of clones is specific to *@auto-md* trees (although I have not 
>> tested other *@auto-xx* trees):
>>
>> In an outline with both *@clean* and an *@auto-md* trees, when the 
>> outline is closed and re-opened, the clone nodes of the *@clean* tree 
>> remained but the clone nodes of the *@auto-md* tree were no longer 
>> clones.
>>
>> I don't know what the original intention was with respect to *@auto-md 
>> *trees, 
>> but this seems like a serious bug to me.  I'll create an issue for it.
>>
>> On Wednesday, May 24, 2023 at 10:10:34 AM UTC-4 Thomas Passin wrote:
>>
>>> I see where the problem is - or at least *a* problem - is, and it's 
>>> serious. The problem I see is that when an outline with clones is 
>>> re-opened, the clones are no longer clones.  This did not happen when I 
>>> created some clones in my Workbook, so there are some conditions yet to be 
>>> determined. I'll experiment some more to try to pin it down.  The outline 
>>> which showed the problem had both an *@auto-md* and an *@clean* tree.  
>>> I'll try outlines with them separately and report back.
>>>
>>> On Wednesday, May 24, 2023 at 8:22:58 AM UTC-4 Thomas Passin wrote:
>>>
>>>> @Edward recently re-worked some of the importers.  If you can use the 
>>>> current version of the devel branch (in GitHub) it would be worth trying.  
>>>> Can you share a tree that suffers from the problem?  Or a minimal version 
>>>> that does?
>>>>
>>>> On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:
>>>>
>>>>> Sorry, it's Leo 6.6.4 on Arch Linux.
>>>>>
>>>>> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>>>>>
>>>>>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>>>>>> file.  It is only a tiny, simple file so maybe it's not enough of a 
>>>>>> test.  
>>>>>> Here is what I did:
>>>>>>
>>>>>> 1. Created an @auto-md file with the following structure:
>>>>>>
>>>>>> @clean c:\temp\leo\md-test-at-auto-md.md
>>>>>> Markdown Test Tree
>>>>>> A1
>>>>>> A1.1
>>>>>> A1.1.1
>>>>>> A2
>>>>>>
>>>>>> 2. I added a line *@others *to the top of the body of the top node.  
>>>>>> I wrote a line or two for most of the nodes.  Then I saved the outline.
>>>>>> 3. I added a new top-level node outside the *@auto-md* node.  I 
>>>>>> cloned node *A1* into it.
>>>>>> 4. In the cloned *A1.1* node, I added a new line.
>>>>>> 5. I observed in an external editor that the *@auto-md* file had the 
>>>>>> intended change.
>>>>>> 6. I closed and reopened the outline.
>>>>>> 7.  I did not see any corruption in the outline.
>>>>>>
>>>>>> Could you write more detail about the *@auto-md* file that ended up 
>>>>>> with a corrupted outline, and whether you use an *@others* line in 
>>>>>> it?  And is this the only such file that caused a problem?  And also the 
>>>>>> version of Leo and the OS (though it doesn't seem likely that the OS is 
>>>>>> playing a part).
>>>>>> On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:
>>>>>>
>>>>>>> Maybe @clean or even @file would work for you (not that I've tried 
>>>>>>> them with clones, which I'll try out soon) instead of @auto-md.  I 
>>>>>>> don't 
>>>>>>> think  that @auto-md really gets you anything that they don't, although 
>>>>>>> you 
>>>>>>> will need t

Re: Impressive ChatGPT responses

[Thomas Passin]

This is an interesting account of someone doing real programming - 
refactoring and simplifying version 1 - with the help of not one but two 
LLM bots.  He wanted to compare how the two differed and how useful each 
would be - When the rubber duck talks back 
<https://blog.jonudell.net/2023/05/24/when-the-rubber-duck-talks-back/>. 
It's especially interesting that - if you are using VSCode, anyway - the 
bot can index your entire repo and use that to give much better results.
On Thursday, May 18, 2023 at 5:42:27 PM UTC-4 Edward K. Ream wrote:

> On Thu, May 18, 2023 at 1:38 PM Thomas Passin  wrote:
>
>> And here is the earlier transcript, reformated - the chatbot's doing a 
>> lot of hand-waving!
>
>
> Imo, the response is drivel.
>
> 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/aedbe41c-1af3-4bbd-b22e-c0e02712fc3an%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

The GitHub issue is 3355 
<https://github.com/leo-editor/leo-editor/issues/3355>.

On Wednesday, May 24, 2023 at 10:40:25 AM UTC-4 Thomas Passin wrote:

> The loss of clones is specific to *@auto-md* trees (although I have not 
> tested other *@auto-xx* trees):
>
> In an outline with both *@clean* and an *@auto-md* trees, when the 
> outline is closed and re-opened, the clone nodes of the *@clean* tree 
> remained but the clone nodes of the *@auto-md* tree were no longer clones.
>
> I don't know what the original intention was with respect to *@auto-md 
> *trees, 
> but this seems like a serious bug to me.  I'll create an issue for it.
>
> On Wednesday, May 24, 2023 at 10:10:34 AM UTC-4 Thomas Passin wrote:
>
>> I see where the problem is - or at least *a* problem - is, and it's 
>> serious. The problem I see is that when an outline with clones is 
>> re-opened, the clones are no longer clones.  This did not happen when I 
>> created some clones in my Workbook, so there are some conditions yet to be 
>> determined. I'll experiment some more to try to pin it down.  The outline 
>> which showed the problem had both an *@auto-md* and an *@clean* tree.  
>> I'll try outlines with them separately and report back.
>>
>> On Wednesday, May 24, 2023 at 8:22:58 AM UTC-4 Thomas Passin wrote:
>>
>>> @Edward recently re-worked some of the importers.  If you can use the 
>>> current version of the devel branch (in GitHub) it would be worth trying.  
>>> Can you share a tree that suffers from the problem?  Or a minimal version 
>>> that does?
>>>
>>> On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:
>>>
>>>> Sorry, it's Leo 6.6.4 on Arch Linux.
>>>>
>>>> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>>>>
>>>>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>>>>> file.  It is only a tiny, simple file so maybe it's not enough of a test. 
>>>>>  
>>>>> Here is what I did:
>>>>>
>>>>> 1. Created an @auto-md file with the following structure:
>>>>>
>>>>> @clean c:\temp\leo\md-test-at-auto-md.md
>>>>> Markdown Test Tree
>>>>> A1
>>>>> A1.1
>>>>> A1.1.1
>>>>> A2
>>>>>
>>>>> 2. I added a line *@others *to the top of the body of the top node.  
>>>>> I wrote a line or two for most of the nodes.  Then I saved the outline.
>>>>> 3. I added a new top-level node outside the *@auto-md* node.  I 
>>>>> cloned node *A1* into it.
>>>>> 4. In the cloned *A1.1* node, I added a new line.
>>>>> 5. I observed in an external editor that the *@auto-md* file had the 
>>>>> intended change.
>>>>> 6. I closed and reopened the outline.
>>>>> 7.  I did not see any corruption in the outline.
>>>>>
>>>>> Could you write more detail about the *@auto-md* file that ended up 
>>>>> with a corrupted outline, and whether you use an *@others* line in 
>>>>> it?  And is this the only such file that caused a problem?  And also the 
>>>>> version of Leo and the OS (though it doesn't seem likely that the OS is 
>>>>> playing a part).
>>>>> On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:
>>>>>
>>>>>> Maybe @clean or even @file would work for you (not that I've tried 
>>>>>> them with clones, which I'll try out soon) instead of @auto-md.  I don't 
>>>>>> think  that @auto-md really gets you anything that they don't, although 
>>>>>> you 
>>>>>> will need to put *@language md* at  the start of the body of the top 
>>>>>> node.
>>>>>>
>>>>>> On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:
>>>>>>
>>>>>>> An example:
>>>>>>>
>>>>>>> @auto-md file1.md
>>>>>>> clone-node_1
>>>>>>> clone-node_2
>>>>>>>
>>>>>>> @auto-md file2.md
>>>>>>> clone-node_1
>>>>>>> clone-node_2
>>>>>>>
>>>>>>> Changes in a clone causes (don't know exactly when, probably when 
>>>>>>> reading the LEO file) that the tree hierarchy is partially destroyed. 
>>>>>>> The 
>>>>>>> content remains, but ends up in a node that didn't exist before and 
>>>>>>> whose 
>>>>>>> heading consists of parts of the content.
>>>>>>>
>>>>>>> I think this could be prevented if @auto-md would only write. Do I 
>>>>>>> see that right? And can I force this somehow?
>>>>>>>
>>>>>>> Best regards
>>>>>>> Paul
>>>>>>
>>>>>>

-- 
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/96a733f2-a3e7-4321-9390-4d9e12b314c6n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

The loss of clones is specific to *@auto-md* trees (although I have not 
tested other *@auto-xx* trees):

In an outline with both *@clean* and an *@auto-md* trees, when the outline 
is closed and re-opened, the clone nodes of the *@clean* tree remained but 
the clone nodes of the *@auto-md* tree were no longer clones.

I don't know what the original intention was with respect to *@auto-md *trees, 
but this seems like a serious bug to me.  I'll create an issue for it.

On Wednesday, May 24, 2023 at 10:10:34 AM UTC-4 Thomas Passin wrote:

> I see where the problem is - or at least *a* problem - is, and it's 
> serious. The problem I see is that when an outline with clones is 
> re-opened, the clones are no longer clones.  This did not happen when I 
> created some clones in my Workbook, so there are some conditions yet to be 
> determined. I'll experiment some more to try to pin it down.  The outline 
> which showed the problem had both an *@auto-md* and an *@clean* tree.  
> I'll try outlines with them separately and report back.
>
> On Wednesday, May 24, 2023 at 8:22:58 AM UTC-4 Thomas Passin wrote:
>
>> @Edward recently re-worked some of the importers.  If you can use the 
>> current version of the devel branch (in GitHub) it would be worth trying.  
>> Can you share a tree that suffers from the problem?  Or a minimal version 
>> that does?
>>
>> On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:
>>
>>> Sorry, it's Leo 6.6.4 on Arch Linux.
>>>
>>> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>>>
>>>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>>>> file.  It is only a tiny, simple file so maybe it's not enough of a test.  
>>>> Here is what I did:
>>>>
>>>> 1. Created an @auto-md file with the following structure:
>>>>
>>>> @clean c:\temp\leo\md-test-at-auto-md.md
>>>> Markdown Test Tree
>>>> A1
>>>> A1.1
>>>> A1.1.1
>>>> A2
>>>>
>>>> 2. I added a line *@others *to the top of the body of the top node.  I 
>>>> wrote a line or two for most of the nodes.  Then I saved the outline.
>>>> 3. I added a new top-level node outside the *@auto-md* node.  I cloned 
>>>> node *A1* into it.
>>>> 4. In the cloned *A1.1* node, I added a new line.
>>>> 5. I observed in an external editor that the *@auto-md* file had the 
>>>> intended change.
>>>> 6. I closed and reopened the outline.
>>>> 7.  I did not see any corruption in the outline.
>>>>
>>>> Could you write more detail about the *@auto-md* file that ended up 
>>>> with a corrupted outline, and whether you use an *@others* line in 
>>>> it?  And is this the only such file that caused a problem?  And also the 
>>>> version of Leo and the OS (though it doesn't seem likely that the OS is 
>>>> playing a part).
>>>> On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:
>>>>
>>>>> Maybe @clean or even @file would work for you (not that I've tried 
>>>>> them with clones, which I'll try out soon) instead of @auto-md.  I don't 
>>>>> think  that @auto-md really gets you anything that they don't, although 
>>>>> you 
>>>>> will need to put *@language md* at  the start of the body of the top 
>>>>> node.
>>>>>
>>>>> On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:
>>>>>
>>>>>> An example:
>>>>>>
>>>>>> @auto-md file1.md
>>>>>> clone-node_1
>>>>>> clone-node_2
>>>>>>
>>>>>> @auto-md file2.md
>>>>>> clone-node_1
>>>>>> clone-node_2
>>>>>>
>>>>>> Changes in a clone causes (don't know exactly when, probably when 
>>>>>> reading the LEO file) that the tree hierarchy is partially destroyed. 
>>>>>> The 
>>>>>> content remains, but ends up in a node that didn't exist before and 
>>>>>> whose 
>>>>>> heading consists of parts of the content.
>>>>>>
>>>>>> I think this could be prevented if @auto-md would only write. Do I 
>>>>>> see that right? And can I force this somehow?
>>>>>>
>>>>>> Best regards
>>>>>> Paul
>>>>>
>>>>>

-- 
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/f9525689-5978-4ca0-afee-559d8c9a8c63n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

I see where the problem is - or at least *a* problem - is, and it's 
serious. The problem I see is that when an outline with clones is 
re-opened, the clones are no longer clones.  This did not happen when I 
created some clones in my Workbook, so there are some conditions yet to be 
determined. I'll experiment some more to try to pin it down.  The outline 
which showed the problem had both an *@auto-md* and an *@clean* tree.  I'll 
try outlines with them separately and report back.

On Wednesday, May 24, 2023 at 8:22:58 AM UTC-4 Thomas Passin wrote:

> @Edward recently re-worked some of the importers.  If you can use the 
> current version of the devel branch (in GitHub) it would be worth trying.  
> Can you share a tree that suffers from the problem?  Or a minimal version 
> that does?
>
> On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:
>
>> Sorry, it's Leo 6.6.4 on Arch Linux.
>>
>> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>>
>>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>>> file.  It is only a tiny, simple file so maybe it's not enough of a test.  
>>> Here is what I did:
>>>
>>> 1. Created an @auto-md file with the following structure:
>>>
>>> @clean c:\temp\leo\md-test-at-auto-md.md
>>> Markdown Test Tree
>>> A1
>>> A1.1
>>> A1.1.1
>>> A2
>>>
>>> 2. I added a line *@others *to the top of the body of the top node.  I 
>>> wrote a line or two for most of the nodes.  Then I saved the outline.
>>> 3. I added a new top-level node outside the *@auto-md* node.  I cloned 
>>> node *A1* into it.
>>> 4. In the cloned *A1.1* node, I added a new line.
>>> 5. I observed in an external editor that the *@auto-md* file had the 
>>> intended change.
>>> 6. I closed and reopened the outline.
>>> 7.  I did not see any corruption in the outline.
>>>
>>> Could you write more detail about the *@auto-md* file that ended up 
>>> with a corrupted outline, and whether you use an *@others* line in it?  
>>> And is this the only such file that caused a problem?  And also the version 
>>> of Leo and the OS (though it doesn't seem likely that the OS is playing a 
>>> part).
>>> On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:
>>>
>>>> Maybe @clean or even @file would work for you (not that I've tried them 
>>>> with clones, which I'll try out soon) instead of @auto-md.  I don't think  
>>>> that @auto-md really gets you anything that they don't, although you will 
>>>> need to put *@language md* at  the start of the body of the top node.
>>>>
>>>> On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:
>>>>
>>>>> An example:
>>>>>
>>>>> @auto-md file1.md
>>>>> clone-node_1
>>>>> clone-node_2
>>>>>
>>>>> @auto-md file2.md
>>>>> clone-node_1
>>>>> clone-node_2
>>>>>
>>>>> Changes in a clone causes (don't know exactly when, probably when 
>>>>> reading the LEO file) that the tree hierarchy is partially destroyed. The 
>>>>> content remains, but ends up in a node that didn't exist before and whose 
>>>>> heading consists of parts of the content.
>>>>>
>>>>> I think this could be prevented if @auto-md would only write. Do I see 
>>>>> that right? And can I force this somehow?
>>>>>
>>>>> Best regards
>>>>> Paul
>>>>
>>>>

-- 
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/f9c0ac81-a08e-47a8-bc60-e5d359ab1cdbn%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

@Edward recently re-worked some of the importers.  If you can use the 
current version of the devel branch (in GitHub) it would be worth trying.  
Can you share a tree that suffers from the problem?  Or a minimal version 
that does?

On Wednesday, May 24, 2023 at 5:12:30 AM UTC-4 p.os...@datec.at wrote:

> Sorry, it's Leo 6.6.4 on Arch Linux.
>
> On Tuesday, May 23, 2023 at 8:17:44 PM UTC+2 tbp1...@gmail.com wrote:
>
>> I tried out what you wrote and didn't get an error with an *@auto-md* 
>> file.  It is only a tiny, simple file so maybe it's not enough of a test.  
>> Here is what I did:
>>
>> 1. Created an @auto-md file with the following structure:
>>
>> @clean c:\temp\leo\md-test-at-auto-md.md
>> Markdown Test Tree
>> A1
>> A1.1
>> A1.1.1
>> A2
>>
>> 2. I added a line *@others *to the top of the body of the top node.  I 
>> wrote a line or two for most of the nodes.  Then I saved the outline.
>> 3. I added a new top-level node outside the *@auto-md* node.  I cloned 
>> node *A1* into it.
>> 4. In the cloned *A1.1* node, I added a new line.
>> 5. I observed in an external editor that the *@auto-md* file had the 
>> intended change.
>> 6. I closed and reopened the outline.
>> 7.  I did not see any corruption in the outline.
>>
>> Could you write more detail about the *@auto-md* file that ended up with 
>> a corrupted outline, and whether you use an *@others* line in it?  And 
>> is this the only such file that caused a problem?  And also the version of 
>> Leo and the OS (though it doesn't seem likely that the OS is playing a 
>> part).
>> On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:
>>
>>> Maybe @clean or even @file would work for you (not that I've tried them 
>>> with clones, which I'll try out soon) instead of @auto-md.  I don't think  
>>> that @auto-md really gets you anything that they don't, although you will 
>>> need to put *@language md* at  the start of the body of the top node.
>>>
>>> On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:
>>>
>>>> An example:
>>>>
>>>> @auto-md file1.md
>>>> clone-node_1
>>>> clone-node_2
>>>>
>>>> @auto-md file2.md
>>>> clone-node_1
>>>> clone-node_2
>>>>
>>>> Changes in a clone causes (don't know exactly when, probably when 
>>>> reading the LEO file) that the tree hierarchy is partially destroyed. The 
>>>> content remains, but ends up in a node that didn't exist before and whose 
>>>> heading consists of parts of the content.
>>>>
>>>> I think this could be prevented if @auto-md would only write. Do I see 
>>>> that right? And can I force this somehow?
>>>>
>>>> Best regards
>>>> Paul
>>>
>>>

-- 
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/90b10d4a-38d7-4679-8365-aeba2ea87c84n%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

I tried out what you wrote and didn't get an error with an *@auto-md* 
file.  It is only a tiny, simple file so maybe it's not enough of a test.  
Here is what I did:

1. Created an @auto-md file with the following structure:

@clean c:\temp\leo\md-test-at-auto-md.md
Markdown Test Tree
A1
A1.1
A1.1.1
A2

2. I added a line *@others *to the top of the body of the top node.  I 
wrote a line or two for most of the nodes.  Then I saved the outline.
3. I added a new top-level node outside the *@auto-md* node.  I cloned node 
*A1* into it.
4. In the cloned *A1.1* node, I added a new line.
5. I observed in an external editor that the *@auto-md* file had the 
intended change.
6. I closed and reopened the outline.
7.  I did not see any corruption in the outline.

Could you write more detail about the *@auto-md* file that ended up with a 
corrupted outline, and whether you use an *@others* line in it?  And is 
this the only such file that caused a problem?  And also the version of Leo 
and the OS (though it doesn't seem likely that the OS is playing a part).
On Tuesday, May 23, 2023 at 1:58:13 PM UTC-4 Thomas Passin wrote:

> Maybe @clean or even @file would work for you (not that I've tried them 
> with clones, which I'll try out soon) instead of @auto-md.  I don't think  
> that @auto-md really gets you anything that they don't, although you will 
> need to put *@language md* at  the start of the body of the top node.
>
> On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:
>
>> An example:
>>
>> @auto-md file1.md
>> clone-node_1
>> clone-node_2
>>
>> @auto-md file2.md
>> clone-node_1
>> clone-node_2
>>
>> Changes in a clone causes (don't know exactly when, probably when reading 
>> the LEO file) that the tree hierarchy is partially destroyed. The content 
>> remains, but ends up in a node that didn't exist before and whose heading 
>> consists of parts of the content.
>>
>> I think this could be prevented if @auto-md would only write. Do I see 
>> that right? And can I force this somehow?
>>
>> Best regards
>> Paul
>
>

-- 
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/956cd11b-2f35-4243-a712-d6c8072d0ffcn%40googlegroups.com.

Re: @auto-ms does not get along with Leo's clones

[Thomas Passin]

Maybe @clean or even @file would work for you (not that I've tried them 
with clones, which I'll try out soon) instead of @auto-md.  I don't think  
that @auto-md really gets you anything that they don't, although you will 
need to put *@language md* at  the start of the body of the top node.

On Tuesday, May 23, 2023 at 12:51:48 PM UTC-4 p.os...@datec.at wrote:

> An example:
>
> @auto-md file1.md
> clone-node_1
> clone-node_2
>
> @auto-md file2.md
> clone-node_1
> clone-node_2
>
> Changes in a clone causes (don't know exactly when, probably when reading 
> the LEO file) that the tree hierarchy is partially destroyed. The content 
> remains, but ends up in a node that didn't exist before and whose heading 
> consists of parts of the content.
>
> I think this could be prevented if @auto-md would only write. Do I see 
> that right? And can I force this somehow?
>
> Best regards
> Paul

-- 
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/035a4781-cfda-45e5-b93f-d8f1764547a3n%40googlegroups.com.

Re: New User's Guide To Leo

[Thomas Passin]

On Thursday, May 18, 2023 at 11:17:52 AM UTC-4 Ben Hancock wrote:

Thomas writes:

I've been thinking that there should be a book on Leo.  I don't think I've 
got another book left in me, but I'm not completely happy with the existing 
docs because I don't think they really match what a new user faces when 
trying to fire up Leo and use it the first few times.   


I'm a new Leo user -- I've been programming in Python for 5+ years, but 
somehow only recently managed to discover it -- and think something like 
this would be very helpful. The tutorials, documentation, and Edward's 
YouTube videos are great. But what I think might be really useful are some 
step-by-step examples of common user stories.

For example:

* I'm a developer working on a small-ish Python project that I collaborate 
on with other people. How can I effectively use Leo to start editing my 
existing code base? How should I go about breaking up parts of the existing 
code into an outline (without actually breaking things)?


It's likely that your whole project can be contained by one Leo outline, or 
two if you want to separate out the documentation from the code. Basically, 
you would import all your project files into the Leo outline as "external" 
files (image files would be exceptions - there's not much point in keeping 
them in Leo since you won't be editing them with a text editor).  Then you 
would tune up and possibly re-organize the outline so that it makes the 
most sense to you.  After the outline has been saved, you would check to 
make sure that the project builds or runs right.   For many projects, the 
external files and the Leo outline(s) are put into GitHub or some other 
repository.

At this point, you can just edit the files within Leo, or you can continue 
to reorganize parts of it when that makes sense.  After that you can start 
thinking about creating scripts to automate actions that you used to kick 
off from the command line.

One consideration is whether your external files should be *@file* or 
*@clean* files.  *@file* files contain Leo "sentinels" that tell Leo how to 
recreate the outline structure of the file. *@clean* files do not contain 
any Leo markup.  It's easier for other (non-Leo) programmers to work with 
*@clean* files, but if they change the code structure too much, Leo may 
have trouble recreating the intended structure (it won't lose any code, 
though).  *@file* files can be annoying to other programmers because of 
Leo's embedded comments, but if they don't change or move the sentinels, 
everything will work fine.

I wrote a few paragraphs about this for my GF4 project: DEVELOPERS READ THIS 

.

For importing the files into an outline, the easiest way is to import them 
one-by-one using the *File/Import Files/Import Any File* menu item.  If 
there are too many files, this will get tedious (though it only needs to be 
done once), and you would probably do better using a recursive import 
script.  There is a model in LeoPyRef.leo - do a search for "recursive", 
find the example script, and then adjust it for your paths and files.  The 
imports will come in with absolute paths, and you should probably change 
them to relative paths - use the *Find* tab to do a search-and-replace on 
headlines only.

Some kinds of files you will probably want or need to keep as *@clean* files 
even if the bulk of your program files will be *@file* files.  These would 
be text files such as readme and markdown files, and possibly shell scripts 
(although these can be *@file* files too).

This sounds complicated, but it's not so bad in practice.  You only do it 
once and then as you get used to working within Leo you will start to 
wonder how you ever were able to manage the project any other way.

-- 
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/54d356d0-0a37-4e04-a385-9f9932480926n%40googlegroups.com.

Re: New User's Guide To Leo

[Thomas Passin]

I've been plugging away New User's Guide.  I've also changed the name of 
the top-level file to *index.html*.  The rest of the URL remains the same:  New 
User's Guide <http://tompassin.net/leo/guide/docs/index.html>.

On Saturday, May 20, 2023 at 7:37:29 PM UTC-4 Thomas Passin wrote:

>
>
> On Saturday, May 20, 2023 at 6:10:24 PM UTC-4 Ben Hancock wrote:
>
> [snip]
>
>
> Hi Rob, 
>
> Thanks. I'd be grateful for your tips. It looks like I can probably get 
> a good start on point 2 (creating documents) with the "Creating 
> Documents from Outlines" tutorial[1], but if there are particular things 
> you've learned that would be helpful for a newbie, please share.
>
>
> I do have some good tips to pass on if you are using ReST and especially 
> Sphinx, including one or two that are probably not quite obvious.  I think 
> that using Leo with Sphinx to generate HTML documentation - once you learn 
> certain key bits - is unbeatable for convenience.  For pdf, the output 
> isn't as good.  That's mostly because the pdf generator doesn't produce the 
> best quality output.  But I haven't tried generating pdf for several years 
> and maybe things have improved.
>  
>
> Learning more about how to use Leo to maintain a small website would be 
> great too. I currenly use a mix of HTML, Go templates, and pandoc for my 
> own site (I'm somehow never satisfied with static site generators out of 
> the box), but it seems like cloned nodes in Leo could go a long way to 
> making maintaining things like shared  sections easier, if I'm 
> understanding things right.
>
>
> Basically, if you can create some boilerplate that can be reused for many 
> sites, then clones will probably be useful.  Bear in mind that clones 
> should normally be within a particular outline;  clones between outlines 
> can cause update problems.  Depending on the details of your workflow, it 
> may be possible to write a Leo script to do all the steps, or some of 
> them.  IOW, you could finalize the files, run the script, and have 
> everything built.  Or, if you can write a batch file that can do all the 
> steps, you could launch that file from within Leo.  And you can write and 
> manage that batch file in Leo itself.
>
> I believe that some people have worked out ways to use Jinja templates, 
> but I'm not one of them.  If you can write Python scripts, you can get Leo 
> itself to do a surprising number of things.
>

-- 
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/cc23d419-c10b-4bc4-8f50-9e389a2dc264n%40googlegroups.com.

Re: New User's Guide To Leo

[Thomas Passin]

On Saturday, May 20, 2023 at 6:10:24 PM UTC-4 Ben Hancock wrote:

[snip]
Hi Rob, 

Thanks. I'd be grateful for your tips. It looks like I can probably get 
a good start on point 2 (creating documents) with the "Creating 
Documents from Outlines" tutorial[1], but if there are particular things 
you've learned that would be helpful for a newbie, please share.


I do have some good tips to pass on if you are using ReST and especially 
Sphinx, including one or two that are probably not quite obvious.  I think 
that using Leo with Sphinx to generate HTML documentation - once you learn 
certain key bits - is unbeatable for convenience.  For pdf, the output 
isn't as good.  That's mostly because the pdf generator doesn't produce the 
best quality output.  But I haven't tried generating pdf for several years 
and maybe things have improved.
 

Learning more about how to use Leo to maintain a small website would be 
great too. I currenly use a mix of HTML, Go templates, and pandoc for my 
own site (I'm somehow never satisfied with static site generators out of 
the box), but it seems like cloned nodes in Leo could go a long way to 
making maintaining things like shared  sections easier, if I'm 
understanding things right.


Basically, if you can create some boilerplate that can be reused for many 
sites, then clones will probably be useful.  Bear in mind that clones 
should normally be within a particular outline;  clones between outlines 
can cause update problems.  Depending on the details of your workflow, it 
may be possible to write a Leo script to do all the steps, or some of 
them.  IOW, you could finalize the files, run the script, and have 
everything built.  Or, if you can write a batch file that can do all the 
steps, you could launch that file from within Leo.  And you can write and 
manage that batch file in Leo itself.

I believe that some people have worked out ways to use Jinja templates, but 
I'm not one of them.  If you can write Python scripts, you can get Leo 
itself to do a surprising number of things.

-- 
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/009ea6df-3513-4b00-8dea-d63e27918909n%40googlegroups.com.

Re: Impressive ChatGPT responses

[Thomas Passin]

And here is the earlier transcript, reformated - the chatbot's doing a lot 
of hand-waving!

write a short user's guide about how to manage a web site with the 
leo-editor, and do not explain what the leo-editor or a web site are

ChatGPT
Sure! Here's a short user's guide on managing a website with the Leo editor:

Install Leo Editor: Begin by installing the Leo editor on your computer. 
Follow the installation instructions specific to your operating system.

Create a Project Outline: Launch the Leo editor and create a new project 
outline. The outline will serve as a hierarchical structure to organize 
your website's files and content.

Set up the Directory Structure: Within the project outline, create 
directories to represent different sections or components of your website, 
such as "Home," "About," "Services," and so on. Use Leo's outlining 
features to create a nested structure if needed.

Create HTML Files: Within each directory, create HTML files using Leo's 
file creation functionality. Give each file a descriptive name that 
reflects its purpose or content.

Write HTML Content: Open the HTML files and write the desired content using 
HTML markup. You can use Leo's outlining capabilities to structure and 
organize the content hierarchically.

Add CSS and JavaScript: If your website requires styling or interactivity, 
create separate CSS and JavaScript files within the appropriate 
directories. Link these files to your HTML files using appropriate HTML 
tags.

Preview and Test: Use the Leo editor's built-in preview functionality to 
view your website locally. Open an HTML file, select the preview option, 
and check the rendered output in the integrated web browser.

Edit and Update: Make changes to the HTML, CSS, and JavaScript files as 
needed to refine your website's design and functionality. Use Leo's 
features for navigation, searching, and editing to manage and update your 
site effectively.

Publish Your Website: Once you are satisfied with the website's content and 
design, use your preferred web hosting service or server to publish your 
website. Upload the HTML, CSS, JavaScript, and other necessary files to the 
appropriate directories on your web server.

Maintenance and Updates: As your website evolves, use the Leo editor to 
manage updates and maintain the site's structure. Add new pages, modify 
existing content, and ensure your website remains up-to-date.

Remember to refer to the Leo editor's documentation and resources for 
detailed information on its features and functionalities. Additionally, 
consult web development resources to learn more about HTML, CSS, and 
JavaScript to enhance your website's design and functionality.



-- 
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/8e8dfeb9-01d0-4931-a4d0-313f80ee1c4fn%40googlegroups.com.