Re: Another YouTube video worth watching twice

[jkn]

I also recommend "Finite and Infinite Games". I haven't heard of 'Good 
Math', thanks for the pointer

On Thursday, May 2, 2024 at 5:13:17 PM UTC+1 gates...@gmail.com wrote:

> Semi-related, James P. Carse's book "Finite and Infinite Games" is a good, 
> if occasionally overtly-spiritual (and easily enough ignored if that kind 
> of thing isn't for you), look at life through the lens of games.
>
> Weirdly, I find all of this to be tied together with Mark Chu-Carroll's 
> "Good Math", which is "just" a meandering path through interesting 
> mathematical concepts, but has opened surprising doors for me when viewed 
> through the lens of game theoretical analysis.
>
> YMMV wildly, of course :)
>
> Jake
>
> On Thu, May 2, 2024 at 12:00 PM Edward K. Ream  wrote:
>
>> This video  is about game 
>> theory and its implications for us and the world.
>>
>> None of us specializes in this area of mathematics so we will all learn a 
>> lot. It changed my view of the world. It will likely change yours.
>>
>> I've just watched this video a second time. Please watch it and pass it 
>> on :-)
>>
>> 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/5d4bffdc-7cbb-4796-9594-73b19f0514bfn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4dfbe409-c086-42ca-9a30-acc929900c28n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[jkn]

Something like this, together with the 'paste a snippet as a file' feature 
I discussed a few weeks ago (and am still playing with) would go a long way 
to stopping me occasionally yearning for some of the features of Obsidian 
and/or Joplin, which I have tried recently.

On Thursday, April 25, 2024 at 2:00:07 PM UTC+1 tbp1...@gmail.com wrote:

> This sounds pretty much what I had in mind.  The freewin plugin actually 
> does the same (in its own separate window). VR/VR3 also replace the 
> rendering widget type depending on what is to be rendered.  Currently VR3 
> can optionally render to a tab in the log frame instead of to a new frame 
> within the overall Leo window.  So we're not far off.
>
> On Thursday, April 25, 2024 at 8:37:59 AM UTC-4 gates...@gmail.com wrote:
>
>> I actually implemented something similar in a private 'leoapp' (app that 
>> lives in a .leo file) I wrote for myself a few years back.  Pretty simple 
>> to get done, IIRC.
>>
>> My general pattern was to have a controller class that contained two 
>> 'view' widgets (a QTextBrowser for rendered HTML, and a QTextEdit for 
>> editing).  The controller class had a wrapper widget that also had an 
>> 'edit' toggle button.  When 'edit' is clicked, a callback is fired off to 
>> remove the active view widget and replace it with the new one (and set some 
>> state in the controller so it doesn't lose track of things).  Content is 
>> updated between the two widgets whenever this swap happens.  Internally 
>> they are two completely different objects, but to the user, the swap is 
>> fairly seamless.
>>
>> I did write this app relying on PyQt5, unfortunately, so I have a fair 
>> bit of updating to do if I want it to work on modern Leo.  Ah well.
>>
>> Jake
>>
>> On Thu, Apr 25, 2024 at 8:10 AM Edward K. Ream  wrote:
>>
>>>
>>>
>>> On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin  wrote:
>>>
 Except that standard Leo nodes don't render graphics and other non-text 
 items.  That's a big difference. We get around it to a degree with VR/VR3. 
  
 Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, 
 we could overlay the rendering frame over the editing frame. We could 
 switch in and out of rendering mode to allow editing.  I bet that wouldn't 
 be too hard. One way would be to use a 2-frame tabbed widget.  Leo would 
 then have no disadvantage compared with Trillium and its ilk, and would 
 keep all of its advantages.

 Yowee!

>>>
>>> I'm interested. Let's see what you can do.
>>>
>>> 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/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%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/71bc2a28-bc67-4269-b7b4-3eaabefaba29n%40googlegroups.com.

Re: I just had successful eye surgury

[jkn]

My best wishes for a swift and complete recovery, Edward.

Jon N


On Thursday, March 28, 2024 at 8:03:52 PM UTC Edward K. Ream wrote:

> A vitrectomy 
> of
>  
> the rt eye. I'll be limited in what I can do for about a week.
>
> 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/09831a35-8b8e-4249-be8a-57b0649639d5n%40googlegroups.com.

Re: PR #3842 merged into devel. Leo's headline decluttering should work as before

[jkn]

Hi Edward
as it happens I have made a couple of local changes recently to improve 
headline decluttering. After I am happy with them shall I submit a pull 
request?

J^n


On Monday, March 25, 2024 at 5:37:01 PM UTC Edward K. Ream wrote:

> PR #3842  suppresses 
> two pyflakes complaints in the code that does headline decluttering.
>
> The changes should be harmless. Please let me know if they aren't :-)
>
> 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/d4ba00cc-17f2-44fa-9255-f1e1b670a7acn%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

I think the fact that (recently discovered) ... there seems to be no method 
getPath() in LeoConfig.py  tells us something.

Not trying to make a big deal of this, mind you...

On Sunday, March 24, 2024 at 12:48:13 PM UTC tbp1...@gmail.com wrote:

> It's still a good question, though.  Is there an actual use for a setting 
> of type "@path"?Having it included in that documentation section seems 
> to imply that there is, though its inclusion may have been meant only as a 
> syntax example. Can anyone resolve this?
>
> On Sunday, March 24, 2024 at 8:24:47 AM UTC-4 Edward K. Ream wrote:
>
>> On Sun, Mar 24, 2024 at 7:01 AM Thomas Passin  wrote:
>>
>>> Settings and headlines are not the same.
>>>
>>
>> At last I understand :-)  As Thomas says, the syntax for settings nodes 
>> is different from directives.
>>
>> In other words, Leo's documentation appears to be correct.
>>
>> 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/1d17bf22-ee22-4c89-a1d3-bc35c0c78df0n%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

I see what you mean... yes, I conflated the two (a site search for '@path' 
got me to the link I mentioned, and not to the canonical documentation 
Edward pointed out)

In that case, can someone give me an example of the use for

@settings
@path mypath = path/to/...

?
Thanks, J^n


On Sunday, March 24, 2024 at 12:01:40 PM UTC tbp1...@gmail.com wrote:

> Settings and headlines are not the same.
>
> On Sunday, March 24, 2024 at 6:39:03 AM UTC-4 jkn wrote:
>
>> Hi Edward
>> I put the link (to a different part of the documentation) in an earlier 
>> post: 
>> https://leo-editor.github.io/leo-editor/customizing.html#simple-settings-nodes
>>
>> The section you reference is clear, and correct. The link above perhaps 
>> references an older syntax?
>>
>> Regards, J^n
>>
>>
>> On Sunday, March 24, 2024 at 10:27:45 AM UTC Edward K. Ream wrote:
>>
>>> On Sun, Mar 24, 2024 at 4:20 AM jkn  wrote:
>>>
>>>>
>>>> I am commenting on the fact that the documentation says that an @path 
>>>> directive (and all the others in the table below) takes the form
>>>>
>>>> @path **=** my/path
>>>>
>>>> whereas in fact no equals sign is necessary (any might well cause an 
>>>> error?)
>>>>
>>>> @path  my/path
>>>>
>>>
>>> I see no equal sign in Leo's directive reference 
>>> <https://leo-editor.github.io/leo-editor/directives.html> page. What 
>>> documentation are you talking about?
>>>
>>> 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/11753fae-a031-482b-90f5-a2c90440139cn%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

Hi Edward
I put the link (to a different part of the documentation) in an earlier 
post: 
https://leo-editor.github.io/leo-editor/customizing.html#simple-settings-nodes

The section you reference is clear, and correct. The link above perhaps 
references an older syntax?

Regards, J^n


On Sunday, March 24, 2024 at 10:27:45 AM UTC Edward K. Ream wrote:

> On Sun, Mar 24, 2024 at 4:20 AM jkn  wrote:
>
>>
>> I am commenting on the fact that the documentation says that an @path 
>> directive (and all the others in the table below) takes the form
>>
>> @path **=** my/path
>>
>> whereas in fact no equals sign is necessary (any might well cause an 
>> error?)
>>
>> @path  my/path
>>
>
> I see no equal sign in Leo's directive reference 
> <https://leo-editor.github.io/leo-editor/directives.html> page. What 
> documentation are you talking about?
>
> 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/4be91dbc-8f22-4be4-89ea-5f4c7c397da1n%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

That's not what I am commenting on - I'm well aware of all of that.

I am commenting on the fact that the documentation says that an @path 
directive (and all the others in the table below) takes the form

@path **=** my/path

whereas in fact no equals sign is necessary (any might well cause an error?)

@path  my/path




On Sunday, March 24, 2024 at 4:10:38 AM UTC tbp1...@gmail.com wrote:

> *@path* headlines must be like this: @path c:/test/python. Use forward 
> slashes even on Windows. The pathlib methods will use forward slashes and 
> output whatever is right for the OS.
>
> On Saturday, March 23, 2024 at 7:14:14 PM UTC-4 jkn wrote:
>
>> BTW [Edward], isn't this documentation, from 
>> https://leo-editor.github.io/leo-editor/customizing.html#simple-settings-nodes,
>>  
>> incorrect - or am I misunderstanding something?
>>
>> """
>> Simple settings nodes have headlines of the form @ name = val. 
>> These settings set the value of name to val, with the indicated type:
>> """
>> ISTM that the headlines are of the form
>>
>> @type val
>>
>> or can you actually write
>>
>> @path = 
>>
>> etc? I can find no examples of this...
>>
>> On Saturday, March 23, 2024 at 10:55:16 PM UTC jkn wrote:
>>
>>> I think I have an earlier version of this snippet from you somewhere - I 
>>> was going to take a look at it for this purpose. So thanks!
>>>
>>> J^n
>>>
>>>
>>> On Saturday, March 23, 2024 at 10:42:32 PM UTC tbp1...@gmail.com wrote:
>>>
>>>> I've been using an "images" subdirectory under the location of the 
>>>> outline, or under the @path location if you use one.  It would make backup 
>>>> or sharing easier than some random location in the file system.  The 
>>>> script 
>>>> could check for its existence and create it if needed.  
>>>>
>>>> Here's how I get the path of the node or it's @path into the clipboard:
>>>>
>>>> """Copy the effective path of the current node to the clipboard.
>>>>
>>>> This command honors @path directives.
>>>> """
>>>> from pathlib import Path
>>>>
>>>> pth = Path(c.fullPath(p))
>>>> if pth.exists():
>>>> if pth.is_file():
>>>> direc = pth.parent
>>>> else:
>>>> direc = pth
>>>> else:
>>>> direc = Path(g.scanAllAtPathDirectives(c, p))
>>>>
>>>> if direc:
>>>> normdir = str(direc.resolve())
>>>> g.app.gui.replaceClipboardWith(normdir)
>>>> else:
>>>> g.es(f"Path {direc} doesn't exist")
>>>>
>>>> BTW, I have this script linked to a button, which is very convenient 
>>>> sometimes.
>>>> On Saturday, March 23, 2024 at 6:30:21 PM UTC-4 jkn wrote:
>>>>
>>>>> Hi Thomas
>>>>> not sure what an undoer would do here? maybe delete the file? 
>>>>> There is no leo-relevant action here (yet)
>>>>>
>>>>> I'm well aware I don't *need* the main(), but I prefer to write this 
>>>>> way. Same as with bash scripts etc. It helps for future modularity, I 
>>>>> find. 
>>>>> Of course, 'YAGNI', but still. f course you are right that main() could 
>>>>> be 
>>>>> more descriptive, this is only a POC.
>>>>>
>>>>> The tricky bit is deciding where to store the clipboard files. 
>>>>> Obsidian has a special action when you click on inserted 'snippet' 
>>>>> images; 
>>>>> it just stores the filename in the 'body', and uses its knowledge of 
>>>>> where 
>>>>> the snippets are located when you do the equivalent of CTRL-click on the 
>>>>> URL
>>>>>
>>>>> Linking the location of the 'snippets' to the leo file and/or node is 
>>>>> an interesting challenge...
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, March 23, 2024 at 10:09:59 PM UTC tbp1...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Looks pretty straightforward.  Perhaps you'll want to make it 
>>>>>> undoable (so far as Leo is concerned).  As a matter of Python 
>>>>>> programming, 
>>>>>> defining a main() function here isn't needed.  If you are only going to 
&

Re: A Script To Insert An Image

[jkn]

BTW [Edward], isn't this documentation, from 
https://leo-editor.github.io/leo-editor/customizing.html#simple-settings-nodes, 
incorrect - or am I misunderstanding something?

"""
Simple settings nodes have headlines of the form @ name = val. These 
settings set the value of name to val, with the indicated type:
"""
ISTM that the headlines are of the form

@type val

or can you actually write

@path = 

etc? I can find no examples of this...

On Saturday, March 23, 2024 at 10:55:16 PM UTC jkn wrote:

> I think I have an earlier version of this snippet from you somewhere - I 
> was going to take a look at it for this purpose. So thanks!
>
> J^n
>
>
> On Saturday, March 23, 2024 at 10:42:32 PM UTC tbp1...@gmail.com wrote:
>
>> I've been using an "images" subdirectory under the location of the 
>> outline, or under the @path location if you use one.  It would make backup 
>> or sharing easier than some random location in the file system.  The script 
>> could check for its existence and create it if needed.  
>>
>> Here's how I get the path of the node or it's @path into the clipboard:
>>
>> """Copy the effective path of the current node to the clipboard.
>>
>> This command honors @path directives.
>> """
>> from pathlib import Path
>>
>> pth = Path(c.fullPath(p))
>> if pth.exists():
>> if pth.is_file():
>> direc = pth.parent
>> else:
>> direc = pth
>> else:
>> direc = Path(g.scanAllAtPathDirectives(c, p))
>>
>> if direc:
>> normdir = str(direc.resolve())
>> g.app.gui.replaceClipboardWith(normdir)
>> else:
>> g.es(f"Path {direc} doesn't exist")
>>
>> BTW, I have this script linked to a button, which is very convenient 
>> sometimes.
>> On Saturday, March 23, 2024 at 6:30:21 PM UTC-4 jkn wrote:
>>
>>> Hi Thomas
>>> not sure what an undoer would do here? maybe delete the file? There 
>>> is no leo-relevant action here (yet)
>>>
>>> I'm well aware I don't *need* the main(), but I prefer to write this 
>>> way. Same as with bash scripts etc. It helps for future modularity, I find. 
>>> Of course, 'YAGNI', but still. f course you are right that main() could be 
>>> more descriptive, this is only a POC.
>>>
>>> The tricky bit is deciding where to store the clipboard files. Obsidian 
>>> has a special action when you click on inserted 'snippet' images; it just 
>>> stores the filename in the 'body', and uses its knowledge of where the 
>>> snippets are located when you do the equivalent of CTRL-click on the URL
>>>
>>> Linking the location of the 'snippets' to the leo file and/or node is an 
>>> interesting challenge...
>>>
>>>
>>>
>>> On Saturday, March 23, 2024 at 10:09:59 PM UTC tbp1...@gmail.com wrote:
>>>
>>>> Looks pretty straightforward.  Perhaps you'll want to make it undoable 
>>>> (so far as Leo is concerned).  As a matter of Python programming, defining 
>>>> a main() function here isn't needed.  If you are only going to use it as a 
>>>> script, then you don't need a function at all. Just unindent those lines 
>>>> of 
>>>> code (and delete the "main()" line) and they will run when the script 
>>>> runs.  No need to call main() at all.   If you want that clipboard part of 
>>>> the block to run and if it succeeds then insert the markdown text into a 
>>>> node, then the function shouldn't be called "main" but something more 
>>>> descriptive.
>>>>
>>>> On Saturday, March 23, 2024 at 4:59:25 PM UTC-4 jkn wrote:
>>>>
>>>>> OK, here is a simple demonstration of part of the feature I am 
>>>>> interested in.
>>>>>
>>>>> When run with an image in the (global) clipboard, it saves this to a 
>>>>> local timestamped file (under ~/tmp), and indicates how a markdown 
>>>>> reference to that file could be inserted.
>>>>>
>>>>> There's plenty more needed but this is the QClipboard part, I think.
>>>>>
>>>>> import os
>>>>> import time
>>>>> 
>>>>> def unique_png_fname():
>>>>> """ return a unique (timestamped) filename to use
>>>>>     """
>>>>> FORMAT="%Y-%m-%d-%H-%M-%S.png"
>>>>> return time.strftime(FORMA

Re: A Script To Insert An Image

[jkn]

I think I have an earlier version of this snippet from you somewhere - I 
was going to take a look at it for this purpose. So thanks!

J^n


On Saturday, March 23, 2024 at 10:42:32 PM UTC tbp1...@gmail.com wrote:

> I've been using an "images" subdirectory under the location of the 
> outline, or under the @path location if you use one.  It would make backup 
> or sharing easier than some random location in the file system.  The script 
> could check for its existence and create it if needed.  
>
> Here's how I get the path of the node or it's @path into the clipboard:
>
> """Copy the effective path of the current node to the clipboard.
>
> This command honors @path directives.
> """
> from pathlib import Path
>
> pth = Path(c.fullPath(p))
> if pth.exists():
> if pth.is_file():
> direc = pth.parent
> else:
> direc = pth
> else:
> direc = Path(g.scanAllAtPathDirectives(c, p))
>
> if direc:
> normdir = str(direc.resolve())
> g.app.gui.replaceClipboardWith(normdir)
> else:
> g.es(f"Path {direc} doesn't exist")
>
> BTW, I have this script linked to a button, which is very convenient 
> sometimes.
> On Saturday, March 23, 2024 at 6:30:21 PM UTC-4 jkn wrote:
>
>> Hi Thomas
>> not sure what an undoer would do here? maybe delete the file? There 
>> is no leo-relevant action here (yet)
>>
>> I'm well aware I don't *need* the main(), but I prefer to write this way. 
>> Same as with bash scripts etc. It helps for future modularity, I find. Of 
>> course, 'YAGNI', but still. f course you are right that main() could be 
>> more descriptive, this is only a POC.
>>
>> The tricky bit is deciding where to store the clipboard files. Obsidian 
>> has a special action when you click on inserted 'snippet' images; it just 
>> stores the filename in the 'body', and uses its knowledge of where the 
>> snippets are located when you do the equivalent of CTRL-click on the URL
>>
>> Linking the location of the 'snippets' to the leo file and/or node is an 
>> interesting challenge...
>>
>>
>>
>> On Saturday, March 23, 2024 at 10:09:59 PM UTC tbp1...@gmail.com wrote:
>>
>>> Looks pretty straightforward.  Perhaps you'll want to make it undoable 
>>> (so far as Leo is concerned).  As a matter of Python programming, defining 
>>> a main() function here isn't needed.  If you are only going to use it as a 
>>> script, then you don't need a function at all. Just unindent those lines of 
>>> code (and delete the "main()" line) and they will run when the script 
>>> runs.  No need to call main() at all.   If you want that clipboard part of 
>>> the block to run and if it succeeds then insert the markdown text into a 
>>> node, then the function shouldn't be called "main" but something more 
>>> descriptive.
>>>
>>> On Saturday, March 23, 2024 at 4:59:25 PM UTC-4 jkn wrote:
>>>
>>>> OK, here is a simple demonstration of part of the feature I am 
>>>> interested in.
>>>>
>>>> When run with an image in the (global) clipboard, it saves this to a 
>>>> local timestamped file (under ~/tmp), and indicates how a markdown 
>>>> reference to that file could be inserted.
>>>>
>>>> There's plenty more needed but this is the QClipboard part, I think.
>>>>
>>>> import os
>>>> import time
>>>> 
>>>> def unique_png_fname():
>>>> """ return a unique (timestamped) filename to use
>>>> """
>>>> FORMAT="%Y-%m-%d-%H-%M-%S.png"
>>>> return time.strftime(FORMAT)
>>>>
>>>> def link_string_md(fname):
>>>> """ get markdown format to insert a filename
>>>> """
>>>> return "![[%s]]" % fname
>>>>
>>>> def main():
>>>> # get clipboard contents - default mode is global clipboard
>>>> cb = g.app.gui.qtApp.clipboard()
>>>> # is it in image format?
>>>> img = cb.image()
>>>> if not img.isNull():
>>>> basefiledir = os.path.expanduser("~/tmp")
>>>> fqfilepath = os.path.join(basefiledir, unique_png_fname())
>>>> img.save(fqfilepath, "PNG")
>>>> g.es("wrote clipboard to:", fqfilepath)
>>>> g.es("could insert:", link_string_md(fqfil

Re: A Script To Insert An Image

[jkn]

Hi Thomas
not sure what an undoer would do here? maybe delete the file? There is 
no leo-relevant action here (yet)

I'm well aware I don't *need* the main(), but I prefer to write this way. 
Same as with bash scripts etc. It helps for future modularity, I find. Of 
course, 'YAGNI', but still. f course you are right that main() could be 
more descriptive, this is only a POC.

The tricky bit is deciding where to store the clipboard files. Obsidian has 
a special action when you click on inserted 'snippet' images; it just 
stores the filename in the 'body', and uses its knowledge of where the 
snippets are located when you do the equivalent of CTRL-click on the URL

Linking the location of the 'snippets' to the leo file and/or node is an 
interesting challenge...



On Saturday, March 23, 2024 at 10:09:59 PM UTC tbp1...@gmail.com wrote:

> Looks pretty straightforward.  Perhaps you'll want to make it undoable (so 
> far as Leo is concerned).  As a matter of Python programming, defining a 
> main() function here isn't needed.  If you are only going to use it as a 
> script, then you don't need a function at all. Just unindent those lines of 
> code (and delete the "main()" line) and they will run when the script 
> runs.  No need to call main() at all.   If you want that clipboard part of 
> the block to run and if it succeeds then insert the markdown text into a 
> node, then the function shouldn't be called "main" but something more 
> descriptive.
>
> On Saturday, March 23, 2024 at 4:59:25 PM UTC-4 jkn wrote:
>
>> OK, here is a simple demonstration of part of the feature I am interested 
>> in.
>>
>> When run with an image in the (global) clipboard, it saves this to a 
>> local timestamped file (under ~/tmp), and indicates how a markdown 
>> reference to that file could be inserted.
>>
>> There's plenty more needed but this is the QClipboard part, I think.
>>
>> import os
>> import time
>> 
>> def unique_png_fname():
>> """ return a unique (timestamped) filename to use
>> """
>> FORMAT="%Y-%m-%d-%H-%M-%S.png"
>> return time.strftime(FORMAT)
>>
>> def link_string_md(fname):
>> """ get markdown format to insert a filename
>> """
>> return "![[%s]]" % fname
>>
>> def main():
>> # get clipboard contents - default mode is global clipboard
>> cb = g.app.gui.qtApp.clipboard()
>> # is it in image format?
>> img = cb.image()
>> if not img.isNull():
>> basefiledir = os.path.expanduser("~/tmp")
>> fqfilepath = os.path.join(basefiledir, unique_png_fname())
>> img.save(fqfilepath, "PNG")
>> g.es("wrote clipboard to:", fqfilepath)
>> g.es("could insert:", link_string_md(fqfilepath))
>> else:
>> g.es("clipboard not in image format")
>>
>> main()
>>
>>
>> On Monday, March 11, 2024 at 8:23:42 PM UTC jkn wrote:
>>
>>> Doh! should have read the documentation better.
>>>
>>> you have to test for a 'null image' using eg. img.isnull()
>>>
>>> on with my trivial experiments...
>>>
>>>
>>> On Monday, March 11, 2024 at 8:10:03 PM UTC jkn wrote:
>>>
>>>> Has anyone played much with class QClipboard? I did a couple of trivial 
>>>> experiments but I must be misunderstanding something.
>>>>
>>>> for instance, QClipboard.image() returns a non-null value even if the 
>>>> clipboard does not contain an image.
>>>>
>>>> J^n
>>>>
>>>>
>>>> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:
>>>>
>>>>> It turns out that to get the relative path conversion w have to remove 
>>>>> any quotation marks around the path before running os.relpath(). So the 
>>>>> script becomes:
>>>>>
>>>>> """Insert RsT code at cursor to display an image.
>>>>>
>>>>> The path to the image file will come from a file dialog.
>>>>> This action is undoable.
>>>>> """
>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>> title="Import File",
>>>>> filetypes=[("All files", "*"),],
>>>>> defaultextension=".*",
>>>>> multiple=False)
>>>>>
>>>>> if PATH:
>>>>> fro

Re: A Script To Insert An Image

[jkn]

OK, here is a simple demonstration of part of the feature I am interested 
in.

When run with an image in the (global) clipboard, it saves this to a local 
timestamped file (under ~/tmp), and indicates how a markdown reference to 
that file could be inserted.

There's plenty more needed but this is the QClipboard part, I think.

import os
import time

def unique_png_fname():
""" return a unique (timestamped) filename to use
"""
FORMAT="%Y-%m-%d-%H-%M-%S.png"
return time.strftime(FORMAT)

def link_string_md(fname):
""" get markdown format to insert a filename
"""
return "![[%s]]" % fname

def main():
# get clipboard contents - default mode is global clipboard
cb = g.app.gui.qtApp.clipboard()
# is it in image format?
img = cb.image()
if not img.isNull():
basefiledir = os.path.expanduser("~/tmp")
fqfilepath = os.path.join(basefiledir, unique_png_fname())
img.save(fqfilepath, "PNG")
g.es("wrote clipboard to:", fqfilepath)
g.es("could insert:", link_string_md(fqfilepath))
else:
g.es("clipboard not in image format")

main()


On Monday, March 11, 2024 at 8:23:42 PM UTC jkn wrote:

> Doh! should have read the documentation better.
>
> you have to test for a 'null image' using eg. img.isnull()
>
> on with my trivial experiments...
>
>
> On Monday, March 11, 2024 at 8:10:03 PM UTC jkn wrote:
>
>> Has anyone played much with class QClipboard? I did a couple of trivial 
>> experiments but I must be misunderstanding something.
>>
>> for instance, QClipboard.image() returns a non-null value even if the 
>> clipboard does not contain an image.
>>
>> J^n
>>
>>
>> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:
>>
>>> It turns out that to get the relative path conversion w have to remove 
>>> any quotation marks around the path before running os.relpath(). So the 
>>> script becomes:
>>>
>>> """Insert RsT code at cursor to display an image.
>>>
>>> The path to the image file will come from a file dialog.
>>> This action is undoable.
>>> """
>>> PATH = g.app.gui.runOpenFileDialog(c,
>>> title="Import File",
>>> filetypes=[("All files", "*"),],
>>> defaultextension=".*",
>>> multiple=False)
>>>
>>> if PATH:
>>> from os.path import relpath
>>> PATH = PATH.replace('"', '').replace("'", '')
>>> PATH = relpath(PATH)
>>> PATH = PATH.replace('\\', '/')
>>>
>>> IMAGE_TEMPLATE = f'''
>>>
>>> .. figure:: {PATH}
>>> :scale: 50%
>>>
>>> '''
>>>
>>> w = c.frame.body.wrapper
>>> p = c.p
>>> s = p.b
>>> u = c.undoer
>>>
>>> start, _ = w.getSelectionRange()
>>>
>>> undoType = 'insert-rst-image-code'
>>> undoData = u.beforeChangeNodeContents(p)
>>>
>>> head, tail = s[:start], s[start:]
>>> p.b = head + IMAGE_TEMPLATE + tail
>>>
>>> c.setChanged()
>>> p.setDirty()
>>> u.afterChangeNodeContents(p, undoType, undoData)
>>> c.redraw()
>>>
>>> On Saturday, March 9, 2024 at 2:04:19 PM UTC-5 Thomas Passin wrote:
>>>
>>>> We can't directly insert an image into a standard Leo node because they 
>>>> are text-only.  I find this very annoying sometimes, especially when I am 
>>>> writing a note and want to include an image.  
>>>>
>>>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>>>> instruction to display an image so that we can view it with the 
>>>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>>>> still annoying to type and I usually forget the exact details. I have a 
>>>> button that toggles VR3 on and off so that it's easy to view an embedded 
>>>> image once the RsT instruction is there. An embedding command would make 
>>>> embedding with Leo as easy as embedding an image in a word processor.  
>>>>  Aha, this is Leo, let's write a script!
>>>>
>>>> Here is a script that pops up a file dialog and inserts a relative path 
>>>> to the chosen file.  There are several small variations which I discuss 
>>>> after the code.
>>>>
>>>> &qu

Re: Small puzzle: where is this focus-to-body action coming from?

[jkn]

On Thursday, March 21, 2024 at 8:07:57 PM UTC gates...@gmail.com wrote:

Oh wow, I completely missed the @ignore.

Curious, my machine does focus-to-body (or something similar, at least) on 
Ctrl+Right too, but I can't find any reason for that keybinding to be in 
place, nor does it show up in my 'show-commands' output either.  Only 
appears to work from the tree or log panes -- once in the body, 
forward-word happens instead (as intended).


yes, that is the behaviour I see
 

I somehow doubt Ctrl+RightArrow equals the same keycode as Tab, because 
Ctrl+RightArrow acts differently from Tab in the body editor.

agreed
 

I wonder if this is some default tab-indexing thing in PyQT that we're not 
un-setting.  Maybe QT has Ctrl+(arrow keys) as default keybindings to 
navigate between widgets?

yes, I am wondering that too

FWIW I realised that 'Ctrl-Next' and 'Ctrl-Prior' refer to what would 
describe as "Ctrl-PgUp' and 'Ctrl-PgDn'.

This is all because I am hoping to implement something that *cycles* pane 
focus. One keystroke to move from tree->body->(maybe)log->tree-> ...

There are probably some gotchas to this, but I have a fixed pane payout...

 

Ctrl+LeftArrow in either tree or log panes also seems to set focus to the 
body pane too.  When I 'float' the body pane (have it in a separate 
window), the behavior stops -- neither Ctrl+Right nor Ctrl+Left do anything 
in the tree pane any longer.

Weird!

Jake

On Thu, Mar 21, 2024 at 3:20 PM jkn  wrote:

Yes, but that is for Alt-d, not the keystrokes I was mentioning.

I see the one that Jake mentions, above, but that seems to be for vi 
emulation, which AFAIK I do not have enabled. Anyway, that setting is 
within an @ignore node. At any rate, I do not have an entry for " 
enter-tree-expand-and-go-right-mode" from 'show-commands'

and I now want to know what keystrokes generate Ctrl-next and Ctrl-prior...

On Thursday, March 21, 2024 at 6:21:02 PM UTC tbp1...@gmail.com wrote:

On Thursday, March 21, 2024 at 2:02:50 PM UTC-4 jkn wrote:

Nevertheless - other @shortcuts I have in myLeoSettings.leo are shown in 
the log output to 'show-commands' - why not this one?


It's in there. My listings for Settings/Show Settings /Show Commands has it:

Alt+d   focus-to-body

It's hard to find things in these listings so I copied it and pasted it 
into a text editor.  A search for the command name located its line. Note 
that either a + or - symbol can be used for bindings, as best I know.

-- 

You received this message because you are subscribed 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/22e3b8f1-93db-4f47-913d-d3321dd75acan%40googlegroups.com
 
<https://groups.google.com/d/msgid/leo-editor/22e3b8f1-93db-4f47-913d-d3321dd75acan%40googlegroups.com?utm_medium=email_source=footer>
.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/88a2cfa4-b9fa-4c6a-84c3-0ad0bd191f36n%40googlegroups.com.

Re: Small puzzle: where is this focus-to-body action coming from?

[jkn]

Yes, but that is for Alt-d, not the keystrokes I was mentioning.

I see the one that Jake mentions, above, but that seems to be for vi 
emulation, which AFAIK I do not have enabled. Anyway, that setting is 
within an @ignore node. At any rate, I do not have an entry for " 
enter-tree-expand-and-go-right-mode" from 'show-commands'

and I now want to know what keystrokes generate Ctrl-next and Ctrl-prior...

On Thursday, March 21, 2024 at 6:21:02 PM UTC tbp1...@gmail.com wrote:

> On Thursday, March 21, 2024 at 2:02:50 PM UTC-4 jkn wrote:
>
> Nevertheless - other @shortcuts I have in myLeoSettings.leo are shown in 
> the log output to 'show-commands' - why not this one?
>
>
> It's in there. My listings for Settings/Show Settings /Show Commands has 
> it:
>
> Alt+d   focus-to-body
>
> It's hard to find things in these listings so I copied it and pasted it 
> into a text editor.  A search for the command name located its line. Note 
> that either a + or - symbol can be used for bindings, as best I know.
>

-- 
You received this message because you are subscribed 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/22e3b8f1-93db-4f47-913d-d3321dd75acan%40googlegroups.com.

Re: Small puzzle: where is this focus-to-body action coming from?

[jkn]

 sorry, I should correct myself. I *do* know about shortcuts - I have 
forgotten that that was the name for the 'bind command to key' settings. I 
was thinking that was '@binding' or something.

Nevertheless - other @shortcuts I have in myLeoSettings.leo are shown in 
the log output to 'show-commands' - why not this one?

Or is it because this (Ctrl-right-arrow) is "Ctrl-Next"? This is shown in 
LeoSettings.leo and in the log pane:

tab-cycle-previous  = Ctrl-Prior
tab-cycle-next  = Ctrl-Next
tab-cycle-next  = Ctrl-Tab

? (I had never though of 'Ctrl-Next', and 'Ctrl-Prior', as referring to 
these key presses)

Great, in that case ... except that for me you can't *cycle* between the 
panes using this, only from tree to body. At least for me ... more 
investigation...

J^n


On Thursday, March 21, 2024 at 5:51:57 PM UTC jkn wrote:

> I am not sure I even know what @shortcuts are! They are hardly mentioned 
> in the docs.
>
> Right, off to investigate, thanks...
>
> On Thursday, March 21, 2024 at 5:28:09 PM UTC tbp1...@gmail.com wrote:
>
>> It's in LeoSettings.leo, in the node @shortcuts Gui operations.
>>
>> On Thursday, March 21, 2024 at 10:33:33 AM UTC-4 jkn wrote:
>>
>>> I keep meaning to look at 'improving' (for my needs) navigation between 
>>> Tree and body panes. Whilst taking a look at this again I found a puzzle.
>>>
>>> I have what is (I think) the standard bindings for this:
>>>
>>> # show-commands
>>> Alt+d   focus-to-body
>>>tree:Tab focus-to-body
>>> focus-to-find
>>> focus-to-log
>>> focus-to-minibuffer
>>> focus-to-spell-tab
>>> Alt+t   focus-to-tree
>>>
>>> However - CTRL+right (ie. main arrow keys on my 107-key KB) seems to do 
>>> focus-to-body as well as TAB.
>>>
>>> Any idea where this binding might be occurring? Is CTRL-right getting 
>>> turned into TAB somewhere? How can I find out, if show-commands gives the 
>>> output above?
>>>
>>> Thanks, jon N
>>>
>>>
>>>

-- 
You received this message because you are subscribed 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/0be80899-b9d8-4acc-afed-e50a74766276n%40googlegroups.com.

Re: Small puzzle: where is this focus-to-body action coming from?

[jkn]

I am not sure I even know what @shortcuts are! They are hardly mentioned in 
the docs.

Right, off to investigate, thanks...

On Thursday, March 21, 2024 at 5:28:09 PM UTC tbp1...@gmail.com wrote:

> It's in LeoSettings.leo, in the node @shortcuts Gui operations.
>
> On Thursday, March 21, 2024 at 10:33:33 AM UTC-4 jkn wrote:
>
>> I keep meaning to look at 'improving' (for my needs) navigation between 
>> Tree and body panes. Whilst taking a look at this again I found a puzzle.
>>
>> I have what is (I think) the standard bindings for this:
>>
>> # show-commands
>> Alt+d   focus-to-body
>>tree:Tab focus-to-body
>> focus-to-find
>> focus-to-log
>> focus-to-minibuffer
>> focus-to-spell-tab
>> Alt+t   focus-to-tree
>>
>> However - CTRL+right (ie. main arrow keys on my 107-key KB) seems to do 
>> focus-to-body as well as TAB.
>>
>> Any idea where this binding might be occurring? Is CTRL-right getting 
>> turned into TAB somewhere? How can I find out, if show-commands gives the 
>> output above?
>>
>> Thanks, jon N
>>
>>
>>

-- 
You received this message because you are subscribed 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/de7a882f-a1ce-4b97-84bf-d75b921e10a1n%40googlegroups.com.

Small puzzle: where is this focus-to-body action coming from?

[jkn]

I keep meaning to look at 'improving' (for my needs) navigation between 
Tree and body panes. Whilst taking a look at this again I found a puzzle.

I have what is (I think) the standard bindings for this:

# show-commands
Alt+d   focus-to-body
   tree:Tab focus-to-body
focus-to-find
focus-to-log
focus-to-minibuffer
focus-to-spell-tab
Alt+t   focus-to-tree

However - CTRL+right (ie. main arrow keys on my 107-key KB) seems to do 
focus-to-body as well as TAB.

Any idea where this binding might be occurring? Is CTRL-right getting 
turned into TAB somewhere? How can I find out, if show-commands gives the 
output above?

Thanks, jon N


-- 
You received this message because you are subscribed 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/6479b10a-ca08-4767-bf1a-15fe3e9ef0ean%40googlegroups.com.

TIL in Leo: environment variables are expanded in @url parameters

[jkn]

I tried this, fully expecting it to fail, but it works!

@url file://${SEAFILE}/rest/of/path/to/my_file

FWIW: I have recently switched from using Nextcloud to sync between 
machines on my local network, to Seafile. I have had a lot of trouble with 
Nextcloud in recent months; Seafile seems to do the one thing it is 
supposed to, with much less fuss than Nextcloud.

So on each machine (Windows/Linux) I have an environment variable SEAFILE 
that points to the top shared director on the local filesystem. This has 
been working for @file nodes, but I hadn't expected it to also work for 
URIs.

Hurrah and Thanks!

https://www.seafile.com   # Open Source File Sync and Document 
Collaboration Platform

-- 
You received this message because you are subscribed 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/0928eea3-10ba-4a0a-9dbc-ee930a002351n%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

Doh! should have read the documentation better.

you have to test for a 'null image' using eg. img.isnull()

on with my trivial experiments...


On Monday, March 11, 2024 at 8:10:03 PM UTC jkn wrote:

> Has anyone played much with class QClipboard? I did a couple of trivial 
> experiments but I must be misunderstanding something.
>
> for instance, QClipboard.image() returns a non-null value even if the 
> clipboard does not contain an image.
>
> J^n
>
>
> On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:
>
>> It turns out that to get the relative path conversion w have to remove 
>> any quotation marks around the path before running os.relpath(). So the 
>> script becomes:
>>
>> """Insert RsT code at cursor to display an image.
>>
>> The path to the image file will come from a file dialog.
>> This action is undoable.
>> """
>> PATH = g.app.gui.runOpenFileDialog(c,
>> title="Import File",
>> filetypes=[("All files", "*"),],
>> defaultextension=".*",
>> multiple=False)
>>
>> if PATH:
>> from os.path import relpath
>> PATH = PATH.replace('"', '').replace("'", '')
>> PATH = relpath(PATH)
>> PATH = PATH.replace('\\', '/')
>>
>> IMAGE_TEMPLATE = f'''
>>
>> .. figure:: {PATH}
>> :scale: 50%
>>
>> '''
>>
>> w = c.frame.body.wrapper
>> p = c.p
>> s = p.b
>> u = c.undoer
>>
>> start, _ = w.getSelectionRange()
>>
>> undoType = 'insert-rst-image-code'
>> undoData = u.beforeChangeNodeContents(p)
>>
>> head, tail = s[:start], s[start:]
>> p.b = head + IMAGE_TEMPLATE + tail
>>
>> c.setChanged()
>> p.setDirty()
>> u.afterChangeNodeContents(p, undoType, undoData)
>> c.redraw()
>>
>> On Saturday, March 9, 2024 at 2:04:19 PM UTC-5 Thomas Passin wrote:
>>
>>> We can't directly insert an image into a standard Leo node because they 
>>> are text-only.  I find this very annoying sometimes, especially when I am 
>>> writing a note and want to include an image.  
>>>
>>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>>> instruction to display an image so that we can view it with the 
>>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>>> still annoying to type and I usually forget the exact details. I have a 
>>> button that toggles VR3 on and off so that it's easy to view an embedded 
>>> image once the RsT instruction is there. An embedding command would make 
>>> embedding with Leo as easy as embedding an image in a word processor.  
>>>  Aha, this is Leo, let's write a script!
>>>
>>> Here is a script that pops up a file dialog and inserts a relative path 
>>> to the chosen file.  There are several small variations which I discuss 
>>> after the code.
>>>
>>> """Insert RsT code at cursor to display an image.
>>>
>>> The path to the image file will come from a file dialog.
>>> This action is undoable.
>>> """
>>> PATH = g.app.gui.runOpenFileDialog(c,
>>> title="Import File",
>>> filetypes=[("All files", "*"),],
>>> defaultextension=".*",
>>> multiple=False)
>>>
>>> if PATH:
>>> from os.path import relpath
>>> PATH = relpath(PATH)
>>> PATH = PATH.replace('\\', '/').replace('"', '').replace("'", '')
>>> IMAGE_TEMPLATE = f'''
>>>
>>> .. figure:: {PATH}
>>> :scale: 50%
>>>
>>> '''
>>> w = c.frame.body.wrapper
>>> p = c.p
>>> s = p.b
>>> u = c.undoer
>>>
>>> start, _ = w.getSelectionRange()
>>>
>>> undoType = 'insert-rst-image-code'
>>> undoData = u.beforeChangeNodeContents(p)
>>>
>>> head, tail = s[:start], s[start:]
>>> p.b = head + IMAGE_TEMPLATE + tail
>>>
>>> c.setChanged()
>>> p.setDirty()
>>> u.afterChangeNodeContents(p, undoType, undoData)
>>> c.redraw()
>>>
>>> Variations:
>>> 1.  If you want an absolute path instead of a relative path, delete the 
>>> lines
>>> from os.path import relpath
>>> PATH = relpath(PATH)
>>> with
>>>

Re: A Script To Insert An Image

[jkn]

Has anyone played much with class QClipboard? I did a couple of trivial 
experiments but I must be misunderstanding something.

for instance, QClipboard.image() returns a non-null value even if the 
clipboard does not contain an image.

J^n


On Monday, March 11, 2024 at 4:33:23 PM UTC tbp1...@gmail.com wrote:

> It turns out that to get the relative path conversion w have to remove any 
> quotation marks around the path before running os.relpath(). So the script 
> becomes:
>
> """Insert RsT code at cursor to display an image.
>
> The path to the image file will come from a file dialog.
> This action is undoable.
> """
> PATH = g.app.gui.runOpenFileDialog(c,
> title="Import File",
> filetypes=[("All files", "*"),],
> defaultextension=".*",
> multiple=False)
>
> if PATH:
> from os.path import relpath
> PATH = PATH.replace('"', '').replace("'", '')
> PATH = relpath(PATH)
> PATH = PATH.replace('\\', '/')
>
> IMAGE_TEMPLATE = f'''
>
> .. figure:: {PATH}
> :scale: 50%
>
> '''
>
> w = c.frame.body.wrapper
> p = c.p
> s = p.b
> u = c.undoer
>
> start, _ = w.getSelectionRange()
>
> undoType = 'insert-rst-image-code'
> undoData = u.beforeChangeNodeContents(p)
>
> head, tail = s[:start], s[start:]
> p.b = head + IMAGE_TEMPLATE + tail
>
> c.setChanged()
> p.setDirty()
> u.afterChangeNodeContents(p, undoType, undoData)
> c.redraw()
>
> On Saturday, March 9, 2024 at 2:04:19 PM UTC-5 Thomas Passin wrote:
>
>> We can't directly insert an image into a standard Leo node because they 
>> are text-only.  I find this very annoying sometimes, especially when I am 
>> writing a note and want to include an image.  
>>
>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>> instruction to display an image so that we can view it with the 
>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>> still annoying to type and I usually forget the exact details. I have a 
>> button that toggles VR3 on and off so that it's easy to view an embedded 
>> image once the RsT instruction is there. An embedding command would make 
>> embedding with Leo as easy as embedding an image in a word processor.  
>>  Aha, this is Leo, let's write a script!
>>
>> Here is a script that pops up a file dialog and inserts a relative path 
>> to the chosen file.  There are several small variations which I discuss 
>> after the code.
>>
>> """Insert RsT code at cursor to display an image.
>>
>> The path to the image file will come from a file dialog.
>> This action is undoable.
>> """
>> PATH = g.app.gui.runOpenFileDialog(c,
>> title="Import File",
>> filetypes=[("All files", "*"),],
>> defaultextension=".*",
>> multiple=False)
>>
>> if PATH:
>> from os.path import relpath
>> PATH = relpath(PATH)
>> PATH = PATH.replace('\\', '/').replace('"', '').replace("'", '')
>> IMAGE_TEMPLATE = f'''
>>
>> .. figure:: {PATH}
>> :scale: 50%
>>
>> '''
>> w = c.frame.body.wrapper
>> p = c.p
>> s = p.b
>> u = c.undoer
>>
>> start, _ = w.getSelectionRange()
>>
>> undoType = 'insert-rst-image-code'
>> undoData = u.beforeChangeNodeContents(p)
>>
>> head, tail = s[:start], s[start:]
>> p.b = head + IMAGE_TEMPLATE + tail
>>
>> c.setChanged()
>> p.setDirty()
>> u.afterChangeNodeContents(p, undoType, undoData)
>> c.redraw()
>>
>> Variations:
>> 1.  If you want an absolute path instead of a relative path, delete the 
>> lines
>> from os.path import relpath
>> PATH = relpath(PATH)
>> with
>>
>> 2. If you  want to get the path from the clipboard instead of a file 
>> dialog, replace the lines
>>
>> PATH = g.app.gui.runOpenFileDialog(c,
>> title="Import File",
>> filetypes=[("All files", "*"),],
>> defaultextension=".*",
>> multiple=False)
>>
>> with the line 
>>
>> PATH = g.app.gui.getTextFromClipboard()
>>
>> 3. If you want the embedded image to be full width instead of 50%, delete 
>> the line
>>
>> :scale: 50%
>>
>> 4. You can make this work with Markdown or Asciidoc by using their 
>> embedding instruction in the TEMPLATE instead of the RsT one.
>>
>> I have added the command to my own local menu.  VR3 can open in a tab in 
>> the log pane; the command for toggling in a tab is *vr3-toggle-tab. * I 
>> usually like opening it in the log pane instead of in its own separate pane.
>>
>> If you would like to create a local menu of your own and don't know how, 
>> it's easy.  Just ask and I'll show what to add to myLeoSettings,leo.
>>
>

-- 
You received this message because you are subscribed 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/f753abeb-9c3f-4f93-a462-54101e9be527n%40googlegroups.com.

Re: A Script To Insert An Image

[jkn]

I am really thinking of the situation where I have already captured an 
image to the clipboard (using some other app...), and then want to paste 
into Leo. But there will undoubtably be something useful in what Terry has 
done

On Saturday, March 9, 2024 at 8:34:45 PM UTC tbp1...@gmail.com wrote:

> Yup, Terry Brown has already done most of it for us in the screen_capture 
> plugin.  Here's the docstring:
>
> """
> screen_capture.py
> =
>
> Capture screen shots - single frames are useful.  The
> `Recorder` class can also capture frames continuously but that's not
> really useful, it doesn't handle audio or video encoding, and can't 
> maintain
> a 30 fps frame rate.  The code for doing so is not hooked up in this 
> plugin.
>
> Screen captures are saved in ``~/.leo/screen_captures`` with
> timestamps in the filenames.
>
> Commands
> 
>
> ``screen-capture-5sec``
>   Wait five seconds, then take a screen shot.
> ``screen-capture-now``
>   Take a screen shot.
>
> Settings
> 
>
> ``@string screen-capture-save-path``
>   Save screen shots here instead of ~/.leo/screen_captures
>
> Terry Brown, terry_...@yahoo.com, Fri Apr 19 16:33:45 2013
> """
>
> The code may need to be updated for Qt6, since it was originally written 
> for Qt4 in 2013. Or just the key capture part of the code could be used, 
> since the entire plugin is more complicated than necessary.  Also it 
> doesn't capture a part of the screen as best as I can see, only the whole.
> On Saturday, March 9, 2024 at 3:27:30 PM UTC-5 jkn wrote:
>
>> I would expect that to be somewhat os-dependant (I mostly use Linux), but 
>> perhaps it is there. I will try to take a look for clipboard-paste 
>> functions.
>>
>>
>>
>> On Saturday, March 9, 2024 at 8:22:44 PM UTC tbp1...@gmail.com wrote:
>>
>>> I seem to remember that somewhere in the code base, Leo code to capture 
>>> the screen has already been worked out.  If that's the case we're in clover.
>>>
>>> On Saturday, March 9, 2024 at 3:09:24 PM UTC-5 jkn wrote:
>>>
>>>> The way I have been using the Obsidian feature is to paste image bytes 
>>>> (eg. from a screen region capture). So Obsidian saves a file:
>>>>
>>>> /path/to/attachments/ 
>>>>
>>>> Pasted image 20240228230106.png
>>>>
>>>>
>>>> Where /path/to/attachments is an Obsidian setting, and the name of the 
>>>> file is clearly a timestamp.
>>>>
>>>>
>>>> Obsidian only uses markdown, so it inserts 
>>>>
>>>>
>>>> ![[Pasted image 20240228230106.png]]
>>>>
>>>>
>>>> into the 'node being edited'
>>>>
>>>>
>>>> I think you can also drag and drop files into a 'node'.
>>>>
>>>>
>>>> There would clearly have to be some work to make this generally useful 
>>>> in a Leo context...
>>>>
>>>>
>>>>
>>>> On Saturday, March 9, 2024 at 7:35:15 PM UTC tbp1...@gmail.com wrote:
>>>>
>>>>> Shouldn't be hard.  What would be on the clipboard?  Image bytes?  Or 
>>>>> an image filename?  I often select an image in a file manager window, 
>>>>> copy 
>>>>> it to an "images" subdirectory of the current outline, then write the 
>>>>> embedding code into and "images" child node.  That would be easy to write 
>>>>> a 
>>>>> script for.
>>>>>
>>>>> On Saturday, March 9, 2024 at 2:14:41 PM UTC-5 jkn wrote:
>>>>>
>>>>>> This looks interesting and useful, thanks Thomas. I confess I 
>>>>>> rarely/never use Leo with images, I really should experiment a little.
>>>>>>
>>>>>> Recently I have been using Obsidian as a note-taking app (Joplin is 
>>>>>> similar). Neither are as capable as Leo, in many ways, but they have 
>>>>>> their 
>>>>>> niceties.
>>>>>> One that is handy when note-taking is the ability to paste *from the 
>>>>>> clipboard*. You can setup an area (directory0 in an Obsidian 'vault' - 
>>>>>> then 
>>>>>> 'paste from clipboard' will
>>>>>> (a) create a unique filename within the image directory, and put the 
>>>>>> clipboard contents in there as eg. a .png file
>>>>>> (b) add a (markdown) reference to the new im

Re: A Script To Insert An Image

[jkn]

I would expect that to be somewhat os-dependant (I mostly use Linux), but 
perhaps it is there. I will try to take a look for clipboard-paste 
functions.



On Saturday, March 9, 2024 at 8:22:44 PM UTC tbp1...@gmail.com wrote:

> I seem to remember that somewhere in the code base, Leo code to capture 
> the screen has already been worked out.  If that's the case we're in clover.
>
> On Saturday, March 9, 2024 at 3:09:24 PM UTC-5 jkn wrote:
>
>> The way I have been using the Obsidian feature is to paste image bytes 
>> (eg. from a screen region capture). So Obsidian saves a file:
>>
>> /path/to/attachments/ 
>>
>> Pasted image 20240228230106.png
>>
>>
>> Where /path/to/attachments is an Obsidian setting, and the name of the 
>> file is clearly a timestamp.
>>
>>
>> Obsidian only uses markdown, so it inserts 
>>
>>
>> ![[Pasted image 20240228230106.png]]
>>
>>
>> into the 'node being edited'
>>
>>
>> I think you can also drag and drop files into a 'node'.
>>
>>
>> There would clearly have to be some work to make this generally useful in 
>> a Leo context...
>>
>>
>>
>> On Saturday, March 9, 2024 at 7:35:15 PM UTC tbp1...@gmail.com wrote:
>>
>>> Shouldn't be hard.  What would be on the clipboard?  Image bytes?  Or an 
>>> image filename?  I often select an image in a file manager window, copy it 
>>> to an "images" subdirectory of the current outline, then write the 
>>> embedding code into and "images" child node.  That would be easy to write a 
>>> script for.
>>>
>>> On Saturday, March 9, 2024 at 2:14:41 PM UTC-5 jkn wrote:
>>>
>>>> This looks interesting and useful, thanks Thomas. I confess I 
>>>> rarely/never use Leo with images, I really should experiment a little.
>>>>
>>>> Recently I have been using Obsidian as a note-taking app (Joplin is 
>>>> similar). Neither are as capable as Leo, in many ways, but they have their 
>>>> niceties.
>>>> One that is handy when note-taking is the ability to paste *from the 
>>>> clipboard*. You can setup an area (directory0 in an Obsidian 'vault' - 
>>>> then 
>>>> 'paste from clipboard' will
>>>> (a) create a unique filename within the image directory, and put the 
>>>> clipboard contents in there as eg. a .png file
>>>> (b) add a (markdown) reference to the new image in the 'note' that you 
>>>> are in.
>>>>
>>>> It'd be nice to have something similar in Leo... ;-)
>>>>
>>>> Regards, Jon N
>>>>
>>>> On Saturday, March 9, 2024 at 7:04:19 PM UTC tbp1...@gmail.com wrote:
>>>>
>>>>> We can't directly insert an image into a standard Leo node because 
>>>>> they are text-only.  I find this very annoying sometimes, especially when 
>>>>> I 
>>>>> am writing a note and want to include an image.  
>>>>>
>>>>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>>>>> instruction to display an image so that we can view it with the 
>>>>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>>>>> still annoying to type and I usually forget the exact details. I have a 
>>>>> button that toggles VR3 on and off so that it's easy to view an embedded 
>>>>> image once the RsT instruction is there. An embedding command would make 
>>>>> embedding with Leo as easy as embedding an image in a word processor.  
>>>>>  Aha, this is Leo, let's write a script!
>>>>>
>>>>> Here is a script that pops up a file dialog and inserts a relative 
>>>>> path to the chosen file.  There are several small variations which I 
>>>>> discuss after the code.
>>>>>
>>>>> """Insert RsT code at cursor to display an image.
>>>>>
>>>>> The path to the image file will come from a file dialog.
>>>>> This action is undoable.
>>>>> """
>>>>> PATH = g.app.gui.runOpenFileDialog(c,
>>>>> title="Import File",
>>>>> filetypes=[("All files", "*"),],
>>>>> defaultextension=".*",
>>>>> multiple=False)
>>>>>
>>>>> if PATH:
>>>>> from os.path import relpath
>>>>>   

Re: A Script To Insert An Image

[jkn]

The way I have been using the Obsidian feature is to paste image bytes (eg. 
from a screen region capture). So Obsidian saves a file:

/path/to/attachments/ 

Pasted image 20240228230106.png


Where /path/to/attachments is an Obsidian setting, and the name of the file 
is clearly a timestamp.


Obsidian only uses markdown, so it inserts 


![[Pasted image 20240228230106.png]]


into the 'node being edited'


I think you can also drag and drop files into a 'node'.


There would clearly have to be some work to make this generally useful in a 
Leo context...



On Saturday, March 9, 2024 at 7:35:15 PM UTC tbp1...@gmail.com wrote:

> Shouldn't be hard.  What would be on the clipboard?  Image bytes?  Or an 
> image filename?  I often select an image in a file manager window, copy it 
> to an "images" subdirectory of the current outline, then write the 
> embedding code into and "images" child node.  That would be easy to write a 
> script for.
>
> On Saturday, March 9, 2024 at 2:14:41 PM UTC-5 jkn wrote:
>
>> This looks interesting and useful, thanks Thomas. I confess I 
>> rarely/never use Leo with images, I really should experiment a little.
>>
>> Recently I have been using Obsidian as a note-taking app (Joplin is 
>> similar). Neither are as capable as Leo, in many ways, but they have their 
>> niceties.
>> One that is handy when note-taking is the ability to paste *from the 
>> clipboard*. You can setup an area (directory0 in an Obsidian 'vault' - then 
>> 'paste from clipboard' will
>> (a) create a unique filename within the image directory, and put the 
>> clipboard contents in there as eg. a .png file
>> (b) add a (markdown) reference to the new image in the 'note' that you 
>> are in.
>>
>> It'd be nice to have something similar in Leo... ;-)
>>
>> Regards, Jon N
>>
>> On Saturday, March 9, 2024 at 7:04:19 PM UTC tbp1...@gmail.com wrote:
>>
>>> We can't directly insert an image into a standard Leo node because they 
>>> are text-only.  I find this very annoying sometimes, especially when I am 
>>> writing a note and want to include an image.  
>>>
>>> But we can do the next best thing - insert an ReStructuredText (RsT) 
>>> instruction to display an image so that we can view it with the 
>>> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
>>> still annoying to type and I usually forget the exact details. I have a 
>>> button that toggles VR3 on and off so that it's easy to view an embedded 
>>> image once the RsT instruction is there. An embedding command would make 
>>> embedding with Leo as easy as embedding an image in a word processor.  
>>>  Aha, this is Leo, let's write a script!
>>>
>>> Here is a script that pops up a file dialog and inserts a relative path 
>>> to the chosen file.  There are several small variations which I discuss 
>>> after the code.
>>>
>>> """Insert RsT code at cursor to display an image.
>>>
>>> The path to the image file will come from a file dialog.
>>> This action is undoable.
>>> """
>>> PATH = g.app.gui.runOpenFileDialog(c,
>>> title="Import File",
>>> filetypes=[("All files", "*"),],
>>> defaultextension=".*",
>>> multiple=False)
>>>
>>> if PATH:
>>> from os.path import relpath
>>> PATH = relpath(PATH)
>>> PATH = PATH.replace('\\', '/').replace('"', '').replace("'", '')
>>> IMAGE_TEMPLATE = f'''
>>>
>>> .. figure:: {PATH}
>>> :scale: 50%
>>>
>>> '''
>>> w = c.frame.body.wrapper
>>> p = c.p
>>> s = p.b
>>> u = c.undoer
>>>
>>> start, _ = w.getSelectionRange()
>>>
>>> undoType = 'insert-rst-image-code'
>>> undoData = u.beforeChangeNodeContents(p)
>>>
>>> head, tail = s[:start], s[start:]
>>> p.b = head + IMAGE_TEMPLATE + tail
>>>
>>> c.setChanged()
>>> p.setDirty()
>>> u.afterChangeNodeContents(p, undoType, undoData)
>>> c.redraw()
>>>
>>> Variations:
>>> 1.  If you want an absolute path instead of a relative path, delete the 
>>> lines
>>> from os.path import relpath
>>> PATH = relpath(PATH)
>>> with
>>>
>>> 2. If you  want to get the path from the clipboard instead of a file 
>>> dialog, replace the lines
>>>
>>

Re: A Script To Insert An Image

[jkn]

This looks interesting and useful, thanks Thomas. I confess I rarely/never 
use Leo with images, I really should experiment a little.

Recently I have been using Obsidian as a note-taking app (Joplin is 
similar). Neither are as capable as Leo, in many ways, but they have their 
niceties.
One that is handy when note-taking is the ability to paste *from the 
clipboard*. You can setup an area (directory0 in an Obsidian 'vault' - then 
'paste from clipboard' will
(a) create a unique filename within the image directory, and put the 
clipboard contents in there as eg. a .png file
(b) add a (markdown) reference to the new image in the 'note' that you are 
in.

It'd be nice to have something similar in Leo... ;-)

Regards, Jon N

On Saturday, March 9, 2024 at 7:04:19 PM UTC tbp1...@gmail.com wrote:

> We can't directly insert an image into a standard Leo node because they 
> are text-only.  I find this very annoying sometimes, especially when I am 
> writing a note and want to include an image.  
>
> But we can do the next best thing - insert an ReStructuredText (RsT) 
> instruction to display an image so that we can view it with the 
> viewrendered3 plugin (VR3). The instruction is short and easy, but it's 
> still annoying to type and I usually forget the exact details. I have a 
> button that toggles VR3 on and off so that it's easy to view an embedded 
> image once the RsT instruction is there. An embedding command would make 
> embedding with Leo as easy as embedding an image in a word processor.  
>  Aha, this is Leo, let's write a script!
>
> Here is a script that pops up a file dialog and inserts a relative path to 
> the chosen file.  There are several small variations which I discuss after 
> the code.
>
> """Insert RsT code at cursor to display an image.
>
> The path to the image file will come from a file dialog.
> This action is undoable.
> """
> PATH = g.app.gui.runOpenFileDialog(c,
> title="Import File",
> filetypes=[("All files", "*"),],
> defaultextension=".*",
> multiple=False)
>
> if PATH:
> from os.path import relpath
> PATH = relpath(PATH)
> PATH = PATH.replace('\\', '/').replace('"', '').replace("'", '')
> IMAGE_TEMPLATE = f'''
>
> .. figure:: {PATH}
> :scale: 50%
>
> '''
> w = c.frame.body.wrapper
> p = c.p
> s = p.b
> u = c.undoer
>
> start, _ = w.getSelectionRange()
>
> undoType = 'insert-rst-image-code'
> undoData = u.beforeChangeNodeContents(p)
>
> head, tail = s[:start], s[start:]
> p.b = head + IMAGE_TEMPLATE + tail
>
> c.setChanged()
> p.setDirty()
> u.afterChangeNodeContents(p, undoType, undoData)
> c.redraw()
>
> Variations:
> 1.  If you want an absolute path instead of a relative path, delete the 
> lines
> from os.path import relpath
> PATH = relpath(PATH)
> with
>
> 2. If you  want to get the path from the clipboard instead of a file 
> dialog, replace the lines
>
> PATH = g.app.gui.runOpenFileDialog(c,
> title="Import File",
> filetypes=[("All files", "*"),],
> defaultextension=".*",
> multiple=False)
>
> with the line 
>
> PATH = g.app.gui.getTextFromClipboard()
>
> 3. If you want the embedded image to be full width instead of 50%, delete 
> the line
>
> :scale: 50%
>
> 4. You can make this work with Markdown or Asciidoc by using their 
> embedding instruction in the TEMPLATE instead of the RsT one.
>
> I have added the command to my own local menu.  VR3 can open in a tab in 
> the log pane; the command for toggling in a tab is *vr3-toggle-tab. * I 
> usually like opening it in the log pane instead of in its own separate pane.
>
> If you would like to create a local menu of your own and don't know how, 
> it's easy.  Just ask and I'll show what to add to myLeoSettings,leo.
>

-- 
You received this message because you are subscribed 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/555b3f5c-24a8-4529-adb4-ebf2d945098cn%40googlegroups.com.

Re: TIL in Leo: decluttering headlines

[jkn]

update - it does seem to work ... but I have seen some strangenesses.

- an exception failure, ~ bad number pof parameters
- a case where no more headlines appear below the 'decluttered' one.

I will continue to investigate...

J^n


On Tuesday, February 20, 2024 at 4:21:54 PM UTC jkn wrote:

> I had never seen this before:
>
> 
> https://leo-editor.github.io/leo-editor/customizing.html#decluttering-headlines
>
> this seems very cool! I have been messing around with node icons, but this 
> seems a much better scheme. Is the documentation up to date?
>
> Regards
> Jon N
>
>

-- 
You received this message because you are subscribed 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/f6a8fac1-4c45-4da3-a257-9cff11d8241en%40googlegroups.com.

TIL in Leo: decluttering headlines

[jkn]

I had never seen this before:


https://leo-editor.github.io/leo-editor/customizing.html#decluttering-headlines

this seems very cool! I have been messing around with node icons, but this 
seems a much better scheme. Is the documentation up to date?

Regards
Jon N

-- 
You received this message because you are subscribed 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/c6114c4c-0cf1-4c56-b445-287fc720dac9n%40googlegroups.com.

Re: [Windows] How to install and run Leo?

[jkn]

heh, I was on (several) Ecco Pro mailing lists for years; Yahoo, groups.io 
etc.

There are still quite a few things I miss about Ecco Pro. A true 
cross-platform version of something like it,
scriptable in Python, would be quite a thing.


On Sunday, February 11, 2024 at 11:11:04 PM UTC Rob wrote:

> I was the 'culprit' who recommended Leo on the ECCO group. I also should 
> have explained that Leo can operate as a single pane outliner by simply 
> hiding the body pane (see screenshot).
>
> Rob...
>
> [image: Screenshot 2024-02-11 180945.jpg]
>
> On Sunday, February 11, 2024 at 9:51:08 AM UTC-5 Edward K. Ream wrote:
>
>>
>>
>> On Sun, Feb 11, 2024 at 7:37 AM Heck Lennon  wrote:
>>
>>> Thanks, it finally worked.
>>
>>
>> Excellent. Thanks for your testing! Your experiences have helped improve 
>> Leo.
>>
>> 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/48431c0d-bade-4c04-bc6c-456efa7f7de9n%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

PS: there's a gentleman in the image above who makes me think of 
Vitalije... ;-)


On Wednesday, January 3, 2024 at 11:36:35 AM UTC jkn wrote:

> Yes, these are very entertaining. How do you create them, out of interest? 
> Perhaps you should have an Avatar for Edward and yourself on the next one...
>
> On Wednesday, January 3, 2024 at 10:46:22 AM UTC Edward K. Ream wrote:
>
>> On Tue, Jan 2, 2024 at 7:32 PM Félix  wrote:
>>
>>> jkn Thank you very much for trying out LeoInteg and LeoJS!!
>>
>>
>> Great illustration :-) Please keep them coming. Let's start a gallery!
>>
>> 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/6e148815-327c-44d1-9fef-87d6c04a7eb8n%40googlegroups.com.

Re: ✨LeoJS beta 0.2.11 Released!

[jkn]

Reminds me of this, a little:

"I asked Chat-GPT to make this pic of my dog increasingly more Scottish" 
https://threadreaderapp.com/thread/1734891462666441075.html


On Tuesday, January 23, 2024 at 1:45:15 PM UTC Edward K. Ream wrote:

> On Mon, Jan 22, 2024 at 10:45 PM Félix wrote:
>
> > Introducing LeoJS Beta 0.2.11
>
> > Similar to the latest LeoInteg release, here's the new features that I 
> added in LeoJS since the last version: 
>
> Many thanks again for your work on LeoInteg and LeoJS!
>
> The Three Lions are looking more and more alike!
>
> Love these graphics :-)
>
> The picture in my mind is Blaise Pascal driving a Roman chariot pulled by 
> three lions labeled Leo, LeoInteg and LeoJS :-)
>
> Edward
>
> [image: banner-leojs-fluo.png]
>
>  [image: banner-descartes-lion.png]
>

-- 
You received this message because you are subscribed 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/61fb2013-075a-41ed-a121-ef95a5fd7db4n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

Yes, I ended up with

@path ${NEXTCLOUD}/dir1/dir2
@file myfile.txt

(I prefer using ${NEXTCLOUD} to $NEXTCLOUD, but that is a very minor point)

one thing I note is that leo says eg:

wrote file myfile.txt

where I would prefer it wrote the full path.

I now seem to have quite a few files scattered around called 
"{{g.app.homedir}}{{sep}}"...

J^n



On Wednesday, January 10, 2024 at 4:49:37 PM UTC tbp1...@gmail.com wrote:

> I just did some testing on Windows, and with an @file node Leo acts as if 
> the os.path functions expanduser() and expandvars() are applied, as well as 
> the  abspath() that would be expected (and probably realpath() but I didn't 
> check that).  This means that you can set an environmental variable, say 
> VAR, and use it in the path expression as $VAR.  I didn't find any 
> variables that seem to have been added by Leo.
>
> I didn't find where in LeoPyRef.leo this all happens.
>
> On Wednesday, January 10, 2024 at 9:53:06 AM UTC-5 jkn wrote:
>
>> On Wednesday, January 10, 2024 at 1:00:58 PM UTC tbp1...@gmail.com wrote:
>>
>> Edward made some changes during this thread, IIRC.
>>
>>
>> Yes ... I was trying to track the end results of this.
>>
>> The description of {{sep}} etc. used to be on the leoeditor.com 
>> documentation,
>> but no longer seems to be there.
>> A short 'migration guide' paragraph would be useful, it was not clear to 
>> me
>> that my nodes with this style of directives need to be changed.
>>  
>>
>> On Wednesday, January 10, 2024 at 5:21:22 AM UTC-5 Edward K. Ream wrote:
>>
>> On Tue, Jan 9, 2024 at 1:14 PM jkn  wrote:
>>
>> did the work that got done here ever get documented? 
>>
>>
>> Luke, use the find command!
>>
>> Searching LeoDocs.leo for "path expression" yields these items from the 
>> 6.1 release notes:
>>
>> - #1338 <https://github.com/leo-editor/leo-editor/issues/1338>: 
>> g.getUrlFromNode must not expand path expressions.
>> - #1341 <https://github.com/leo-editor/leo-editor/issues/1341>: 
>> Expansion of path expressions should be strictly limited.
>>
>> My only memory of these issues is that path expressions *must not* 
>> execute arbitrary code!
>>
>> It looks like the fixes happened before Leo started using PRs, so it's 
>> much harder to pinpoint the actual changes.
>>
>> 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/c190db36-761b-4fb6-b3ac-48de442fc9bfn%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

On Wednesday, January 10, 2024 at 1:00:58 PM UTC tbp1...@gmail.com wrote:

Edward made some changes during this thread, IIRC.


Yes ... I was trying to track the end results of this.

The description of {{sep}} etc. used to be on the leoeditor.com 
documentation,
but no longer seems to be there.
A short 'migration guide' paragraph would be useful, it was not clear to me
that my nodes with this style of directives need to be changed.
 

On Wednesday, January 10, 2024 at 5:21:22 AM UTC-5 Edward K. Ream wrote:

On Tue, Jan 9, 2024 at 1:14 PM jkn  wrote:

did the work that got done here ever get documented? 


Luke, use the find command!

Searching LeoDocs.leo for "path expression" yields these items from the 6.1 
release notes:

- #1338 <https://github.com/leo-editor/leo-editor/issues/1338>: 
g.getUrlFromNode must not expand path expressions.
- #1341 <https://github.com/leo-editor/leo-editor/issues/1341>: Expansion 
of path expressions should be strictly limited.

My only memory of these issues is that path expressions *must not* execute 
arbitrary code!

It looks like the fixes happened before Leo started using PRs, so it's much 
harder to pinpoint the actual changes.

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/84bbc53b-d0a1-4add-abae-a2d30587b9d2n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

heh again ... that caused a little bit of head scratching...

I wanted an environment variable $NEXTCLOUD, because the name of my 
nextcloud directory is different
on different machines. But this didn't seem to be working, even though 
$HOME seemed to work.

But I had this line:

export NEXTCLOUD=~/nextCloud

in ~/.bashrc ... which is not applicable if I start leo from the desktop

I was confused because if I typed 'env' in a terminal, I *would* see the 
value.

So I moved the line to ~/.profile, and this behaves as I expect.

I remember when I first learned about the original path specifiers, with 
{{g.app.homedir}}
and {{sep}}, I thought "hmm ... there must be a good reason why Edward 
hasn't used the python
os.path functions to sort this out". I must have been carrying that thought 
with me for a while...

The documentation could do with improving around here though ... in fact I 
don't think
there is currently anything on path descriptors at all. The availability of 
$(ENVVAR} at
least would be useful.

Thanks for listening ... J^n


On Tuesday, January 9, 2024 at 9:37:43 PM UTC jkn wrote:

> heh - see from a closer reading of the code and 
> https://github.com/leo-editor/leo-editor/pull/3264 that
> ${ENVNAME} should already be supported, via os.path.expandvars().
>
> I'm still having a little trouble getting the new form(s) to work as I 
> expect,
> i will experiment a bit more and report back.
>
> On Tuesday, January 9, 2024 at 7:14:33 PM UTC jkn wrote:
>
>> did the work that got done here ever get documented? I am looking at some
>> nodes with old-style path expressions and I am a bit confused what the 
>> current state of the art is.
>> Path expressions don't seem to be discussed in the current documentation.
>>
>> FWIW, in relation to the posting above this, I would suggest that 
>> ${ENVNAME} works in a similar way to $ENVNAME - like in bash scripts, for 
>> instance.
>>
>> Happy New Year!
>> Jon N
>>
>>
>> On Sunday, April 9, 2023 at 12:46:47 AM UTC+1 Edward K. Ream wrote:
>>
>>> On Saturday, April 8, 2023 at 5:52:20 PM UTC-5 tbp1...@gmail.com wrote:
>>>
>>> Excellent!  And if Leo were to export, say, LEODIR, which would be the 
>>> *leo* directory, then there would not be a need for {leoDir} since one 
>>> could write something like 
>>>
>>> @file $LEODIR/themes/vr3/rst-dark.css
>>>
>>> I like it.
>>>
>>>
>>> So do I. The new code will be ready later this evening.
>>>
>>> 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/f818fe95-1a77-484c-b263-924159495b20n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

heh - see from a closer reading of the code and 
https://github.com/leo-editor/leo-editor/pull/3264 that
${ENVNAME} should already be supported, via os.path.expandvars().

I'm still having a little trouble getting the new form(s) to work as I 
expect,
i will experiment a bit more and report back.

On Tuesday, January 9, 2024 at 7:14:33 PM UTC jkn wrote:

> did the work that got done here ever get documented? I am looking at some
> nodes with old-style path expressions and I am a bit confused what the 
> current state of the art is.
> Path expressions don't seem to be discussed in the current documentation.
>
> FWIW, in relation to the posting above this, I would suggest that 
> ${ENVNAME} works in a similar way to $ENVNAME - like in bash scripts, for 
> instance.
>
> Happy New Year!
> Jon N
>
>
> On Sunday, April 9, 2023 at 12:46:47 AM UTC+1 Edward K. Ream wrote:
>
>> On Saturday, April 8, 2023 at 5:52:20 PM UTC-5 tbp1...@gmail.com wrote:
>>
>> Excellent!  And if Leo were to export, say, LEODIR, which would be the 
>> *leo* directory, then there would not be a need for {leoDir} since one 
>> could write something like 
>>
>> @file $LEODIR/themes/vr3/rst-dark.css
>>
>> I like it.
>>
>>
>> So do I. The new code will be ready later this evening.
>>
>> 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/ac9560f5-315b-4b47-9099-ff22b2d0df8dn%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

did the work that got done here ever get documented? I am looking at some
nodes with old-style path expressions and I am a bit confused what the 
current state of the art is.
Path expressions don't seem to be discussed in the current documentation.

FWIW, in relation to the posting above this, I would suggest that 
${ENVNAME} works in a similar way to $ENVNAME - like in bash scripts, for 
instance.

Happy New Year!
Jon N


On Sunday, April 9, 2023 at 12:46:47 AM UTC+1 Edward K. Ream wrote:

> On Saturday, April 8, 2023 at 5:52:20 PM UTC-5 tbp1...@gmail.com wrote:
>
> Excellent!  And if Leo were to export, say, LEODIR, which would be the 
> *leo* directory, then there would not be a need for {leoDir} since one 
> could write something like 
>
> @file $LEODIR/themes/vr3/rst-dark.css
>
> I like it.
>
>
> So do I. The new code will be ready later this evening.
>
> 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/ec729db9-1166-4586-99d3-f4e60f35b376n%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

Yes, these are very entertaining. How do you create them, out of interest? 
Perhaps you should have an Avatar for Edward and yourself on the next one...

On Wednesday, January 3, 2024 at 10:46:22 AM UTC Edward K. Ream wrote:

> On Tue, Jan 2, 2024 at 7:32 PM Félix  wrote:
>
>> jkn Thank you very much for trying out LeoInteg and LeoJS!!
>
>
> Great illustration :-) Please keep them coming. Let's start a gallery!
>
> 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/095ee7a0-2d70-4808-8c85-4d138deb93f5n%40googlegroups.com.

Re: LeoJS - How To Print javascript Output?

[jkn]

Yes, "es" == "emit string" is one of the arcane bits of Leo-lore, IMO. I 
think the docs should mention this, IIRC they do not and it must have 
caused some puzzlement over the years...

On Wednesday, January 3, 2024 at 2:02:15 AM UTC tbp1...@gmail.com wrote:

> Ha! Should have tried that right off!.  Thanks.
>
> On Tuesday, January 2, 2024 at 8:16:51 PM UTC-5 Félix wrote:
>
>> Hi Thomas! :)
>>
>> I gather that by an 'Output window' you mean the LeoJS Log Window? (The 
>> equivalent of Leo's Log Window)
>> [image: log_pane.png]
>>
>> Using *console.log (*which is indeed the equivalent of python's *print 
>> *function, 
>> which prints in the terminal instead of Leo's Log Window), will itself 
>> indeed print in the developer's-tools-terminal. (not recommended)
>>
>> What I recommend in contrast, is the *g.es  *function (and 
>> other 'g' methods like es_print, etc.) which does print in the Log Window. 
>>
>> See (and study) this example script that gives a few pointers on how to 
>> do various useful stuff :
>>
>> @language javascript
>> const vscode = g.app.vscode;
>> g.es("hahahaha");
>> // 'await' for doCommandByName required only if other code in script is 
>> 'awaited'.
>> await c.doCommandByName('insert-headline-time');
>>
>> const userInput = await vscode.window.showInputBox({
>> placeHolder: 'Enter something', // Placeholder text in the input box
>> prompt: 'Please enter some text:', // Prompt message above the input 
>> box
>> });
>> if (userInput === undefined) {
>> g.es('User canceled the input.');
>> } else {
>> g.es('User input:', userInput);
>> }
>> try {
>> const apiUrl = 'https://jsonplaceholder.typicode.com/users';
>> const response = await fetch(apiUrl);
>> g.es("about to call");
>> if (!response.ok) {
>> throw new Error('Network response was not ok');
>> }
>> const data = await response.json();
>> g.es("got it!!", JSON.stringify(data));
>> } catch (error) {
>> g.es("oh no!");
>> console.error('Fetch error:', error);
>> }
>>
>>
>> It will insert the current time on the selected node, then pop an input 
>> box and print it back out in the log window, along with the result of an 
>> HTTP fetch call to some test API. Here is a screenshot of the result of 
>> running this script online in vscode on the web :
>> [image: screen_script_web.png]
>>
>> Hope this helps! 
>>
>> Félix
>>
>> On Tuesday, January 2, 2024 at 12:43:46 PM UTC-5 tbp1...@gmail.com wrote:
>>
>>> This script apparently runs without error but nothing shows in the 
>>> Output window:
>>>
>>> @language javascript
>>> console.log('this is another test');
>>>
>>> Using print() doesn't work, of course, because there isn't a print() 
>>> function.  How can we get a visible output?
>>>
>>

-- 
You received this message because you are subscribed 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/d7fd99f7-6e40-495f-9d1f-ba3c06673f6dn%40googlegroups.com.

Re: Strangeness with tratment of node Icons - LeoJS and/or 'Classic'?

[jkn]

Hi Felix - yes, I will try to make a small file that demonstrates the 
issue. I think the long hex string must be a path to a file (encoded), but 
I am not sure of the mechanism.

IIRC LeoJS indicated this as some sort of note attribute (JSON?), but I 
need to re-run properly so as to give a more useful error report.

Regards, Jon N

On Wednesday, January 3, 2024 at 1:37:39 AM UTC Félix wrote:

> jkn
>
> Can you give more info about those node icons? (custom attributes) Is the 
> long hex string image file data, of just a path to a file on disk?
>
> and share a sample .leo file that has only one or two nodes with icons ? 
> (the smaller the better) I'll use it to make experiments and ensure that it 
> gets read and written as-is to not corrupt any Leo files with custom 
> attributes outside of regular 'UA's
>
> I'll open an issue as soon as I can try it out.
>
> Thanks again!
>
> Félix
> On Tuesday, January 2, 2024 at 12:11:05 PM UTC-5 jkn wrote:
>
>> Has anything changed in the treatment of node Icons recently, please?
>>
>> In the course of trying out LeoJS recently, and getting in a few knots 
>> re. 'file already open in another copy of Leo', I also hit an error where 
>> Leo 'classic' was failing to fully read a file. This seemed to be related 
>> to my occasional use of node icons.
>>
>> AFAICT a node icon just gets turned into an "icons=long_hex_string" in 
>> the node entry:
>>
>> > icons="5d71007d71012858040074797065710258040066696c65710368035834002f686f6d652f6a6b6e2f6c656f2d656469746f722f686561646c696e652d6974656d732f746869737765656b5f67726e2e706e67710458070072656c5061746871055834002f686f6d652f6a6b6e2f6c656f2d656469746f722f686561646c696e652d6974656d732f746869737765656b5f67726e2e706e67710658050077686572657107580e006265666f7265486561646c696e657108580700796f73657471094b00580700786f736574710a4b0258040078706164710b4b015802006f6e710c580500564e6f6465710d75612e">
>>
>> ### (body of node) ###
>> 
>>
>> I'm unclear of the encoding, but FWIW I seemed to have recovered things, 
>> and allowed Leo Classic to open the files, by deleting the 'icons=' part in 
>> my file - luckily there were only a few of them.
>>
>> Perhaps foolishly I did update my copy of Leo classic in the middle of 
>> all of my playing.
>> But I'm wondering if LeoJS somehow mangled something here, or if recent 
>> changes to Leo might have caused this.
>>
>> I can try to recreate the problem and get a fuller error message if that 
>> would be useful. I thought I'd put this out in case this jogged any 
>> memories.
>>
>> Thanks, Jon n
>>
>>

-- 
You received this message because you are subscribed 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/ae9f2353-c81e-4672-9780-89875a4b30a1n%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

Yes, this seems to be a Kubuntu/Codium interaction issue. I 'fixed' it with 
a window management workaround.

On Tuesday, January 2, 2024 at 9:02:25 PM UTC tbp1...@gmail.com wrote:

> On Tuesday, January 2, 2024 at 10:36:44 AM UTC-5 jkn wrote:
>
> (I have also probably been getting confused between LeoInteg and LeoJS: 
> the page Felix links to has 'how to install LeoInteg' at the top...)
>
> I have two issues on first attempts to use LeoJS, or at least to use it in 
> the same environment as I run 'Leo Classic' in:
>
> 1) This is probably OS/distribution specific. I am running VSCodium under 
> Kubuntu Linux. When I try to open a file, the open dialog appear *in the 
> panel/toolbar*, ie. not as a sized window. I have to explicitly open the 
> dialog by clicking in the toolbar. as I say, I think this is an artefact of 
> my distribution, but if anyone knows how to fix it I'd be grateful
>
>
> I just installed it on XUbuntu and didn't see this issue. 
>

-- 
You received this message because you are subscribed 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/8ea04b73-ea15-40a6-afec-b097abdcc99en%40googlegroups.com.

Strangeness with tratment of node Icons - LeoJS and/or 'Classic'?

[jkn]

Has anything changed in the treatment of node Icons recently, please?

In the course of trying out LeoJS recently, and getting in a few knots re. 
'file already open in another copy of Leo', I also hit an error where Leo 
'classic' was failing to fully read a file. This seemed to be related to my 
occasional use of node icons.

AFAICT a node icon just gets turned into an "icons=long_hex_string" in the 
node entry:



### (body of node) ###


I'm unclear of the encoding, but FWIW I seemed to have recovered things, 
and allowed Leo Classic to open the files, by deleting the 'icons=' part in 
my file - luckily there were only a few of them.

Perhaps foolishly I did update my copy of Leo classic in the middle of all 
of my playing.
But I'm wondering if LeoJS somehow mangled something here, or if recent 
changes to Leo might have caused this.

I can try to recreate the problem and get a fuller error message if that 
would be useful. I thought I'd put this out in case this jogged any 
memories.

Thanks, Jon n

-- 
You received this message because you are subscribed 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/c454772a-4cf9-49b5-860c-3084719291fbn%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

update:

1) I have got past my 'files open in another instance of Leo' problem. I 
did remember that the cache is in ~/.leo/db etc, although I ended up not 
doing it this way
2) I also seem to have sorted out my dialog opening issue - it does indeed 
seem to be a VSCodium/Kubuntu problem. I have added a workaround rule to 
the Window configuration.

In the course of all of this I have updated 'Leo classic' and seem to have 
hit a different issue ... I will raise as a separate thread.

Sorry for the noise, J^n


On Tuesday, January 2, 2024 at 3:36:44 PM UTC jkn wrote:

> (I have also probably been getting confused between LeoInteg and LeoJS: 
> the page Felix links to has 'how to install LeoInteg' at the top...)
>
> I have two issues on first attempts to use LeoJS, or at least to use it in 
> the same environment as I run 'Leo Classic' in:
>
> 1) This is probably OS/distribution specific. I am running VSCodium under 
> Kubuntu Linux. When I try to open a file, the open dialog appear *in the 
> panel/toolbar*, ie. not as a sized window. I have to explicitly open the 
> dialog by clicking in the toolbar. as I say, I think this is an artefact of 
> my distribution, but if anyone knows how to fix it I'd be grateful
>
> 2) I am getting severe problems, having exited Codium and trying to start 
> 'Leo Classic', with 'File already opened in another copy of Leo' errors. It 
> took me a while to find the button to close a file in LeoJS; but even after 
> going through the list of files and doing this one by one I am still 
> getting this on multiple files. I recall there used to be some sort of 
> cache file you could delete in these circumstances, but I can recall the 
> details. anyone, please?
>
> Thanks, J^n
>
> On Tuesday, January 2, 2024 at 2:36:02 PM UTC tbp1...@gmail.com wrote:
>
>> That would probably be hard for a developer to keep up with, I would 
>> think.  I remember the first time I went to install leoJS I got a similar 
>> message, but VSC/odium upgraded in a flash so that I hardly knew what had 
>> happened.  So it was a non-issue for me.
>>
>> On Tuesday, January 2, 2024 at 9:24:18 AM UTC-5 jkn wrote:
>>
>>> A small point - it would be nice if the release notes mentioned what 
>>> version of VSCode/VSCodium
>>> was needed. I got a message that my version was too old.
>>> (I am running 1.77.1 of VSCodium, will upgrade shortly)
>>>
>>> Thanks, jon N
>>>
>>> On Tuesday, January 2, 2024 at 9:43:20 AM UTC jkn wrote:
>>>
>>>> I like the graphic Felix, well done! ;-)
>>>>
>>>> Jon N
>>>>
>>>> On Tuesday, January 2, 2024 at 3:38:21 AM UTC Félix wrote:
>>>>
>>>>> Introducing LeoJS Beta 0.2.8
>>>>> LeoJS Beta 0.2.8 is here, bringing a substantial update filled with 
>>>>> enhancements and critical fixes.
>>>>> [image: _56d93bdf-e7f0-4625-85a2-cbf3cfc87fee.jpg]
>>>>>
>>>>> What's New in 0.2.8:
>>>>>
>>>>>- *Help Commands*: 'helpCommands.py' was converted to typescript, 
>>>>>enabling help commands.
>>>>>- *UNL Support*: Works in log pane, body panes, and all editor 
>>>>>windows.
>>>>>- *Goto-Script Fix*: Now works seamlessly with @button items.
>>>>>- *Markdown*: The @auto markdown importer and writer now ensures 
>>>>>flawless read-write integrity.
>>>>>- *Undo/Redo for UAs*: Enhanced command support for 'Clear UAs' 
>>>>>and 'Set UA'.
>>>>>- *Clone Related Commands*: Fixes to 'show clone ancestors' and 
>>>>>'show clone parents' commands.
>>>>>- *Workspace-Specific Sessions*: Session management is now more 
>>>>>personalized with workspace-specific settings.
>>>>>- *Stable Node Selection*: LeoJS maintains focus on the selected 
>>>>>node when refreshing external files.
>>>>>- *gnx-kind Setting*: Choose between uuid, ksuid, or traditional 
>>>>>GNX.
>>>>>
>>>>>  Continuous Improvements Since Launch:
>>>>>
>>>>>- Refined tooltips, language coloring support, and bug fixes in 
>>>>>various importers.
>>>>>- Enhanced keyboard navigation and pattern support for web 
>>>>>browsers.
>>>>>- Streamlined mobile experience, including 'ConfirmBeforeClose' 
>>>>>improvements.
>>>>>- Resolved issues with goto-next-clone and goto-next-marked

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

(I have also probably been getting confused between LeoInteg and LeoJS: the 
page Felix links to has 'how to install LeoInteg' at the top...)

I have two issues on first attempts to use LeoJS, or at least to use it in 
the same environment as I run 'Leo Classic' in:

1) This is probably OS/distribution specific. I am running VSCodium under 
Kubuntu Linux. When I try to open a file, the open dialog appear *in the 
panel/toolbar*, ie. not as a sized window. I have to explicitly open the 
dialog by clicking in the toolbar. as I say, I think this is an artefact of 
my distribution, but if anyone knows how to fix it I'd be grateful

2) I am getting severe problems, having exited Codium and trying to start 
'Leo Classic', with 'File already opened in another copy of Leo' errors. It 
took me a while to find the button to close a file in LeoJS; but even after 
going through the list of files and doing this one by one I am still 
getting this on multiple files. I recall there used to be some sort of 
cache file you could delete in these circumstances, but I can recall the 
details. anyone, please?

Thanks, J^n

On Tuesday, January 2, 2024 at 2:36:02 PM UTC tbp1...@gmail.com wrote:

> That would probably be hard for a developer to keep up with, I would 
> think.  I remember the first time I went to install leoJS I got a similar 
> message, but VSC/odium upgraded in a flash so that I hardly knew what had 
> happened.  So it was a non-issue for me.
>
> On Tuesday, January 2, 2024 at 9:24:18 AM UTC-5 jkn wrote:
>
>> A small point - it would be nice if the release notes mentioned what 
>> version of VSCode/VSCodium
>> was needed. I got a message that my version was too old.
>> (I am running 1.77.1 of VSCodium, will upgrade shortly)
>>
>> Thanks, jon N
>>
>> On Tuesday, January 2, 2024 at 9:43:20 AM UTC jkn wrote:
>>
>>> I like the graphic Felix, well done! ;-)
>>>
>>> Jon N
>>>
>>> On Tuesday, January 2, 2024 at 3:38:21 AM UTC Félix wrote:
>>>
>>>> Introducing LeoJS Beta 0.2.8
>>>> LeoJS Beta 0.2.8 is here, bringing a substantial update filled with 
>>>> enhancements and critical fixes.
>>>> [image: _56d93bdf-e7f0-4625-85a2-cbf3cfc87fee.jpg]
>>>>
>>>> What's New in 0.2.8:
>>>>
>>>>- *Help Commands*: 'helpCommands.py' was converted to typescript, 
>>>>enabling help commands.
>>>>- *UNL Support*: Works in log pane, body panes, and all editor 
>>>>windows.
>>>>- *Goto-Script Fix*: Now works seamlessly with @button items.
>>>>- *Markdown*: The @auto markdown importer and writer now ensures 
>>>>flawless read-write integrity.
>>>>- *Undo/Redo for UAs*: Enhanced command support for 'Clear UAs' and 
>>>>'Set UA'.
>>>>- *Clone Related Commands*: Fixes to 'show clone ancestors' and 
>>>>'show clone parents' commands.
>>>>- *Workspace-Specific Sessions*: Session management is now more 
>>>>personalized with workspace-specific settings.
>>>>- *Stable Node Selection*: LeoJS maintains focus on the selected 
>>>>node when refreshing external files.
>>>>- *gnx-kind Setting*: Choose between uuid, ksuid, or traditional 
>>>>GNX.
>>>>
>>>>  Continuous Improvements Since Launch:
>>>>
>>>>- Refined tooltips, language coloring support, and bug fixes in 
>>>>various importers.
>>>>- Enhanced keyboard navigation and pattern support for web browsers.
>>>>- Streamlined mobile experience, including 'ConfirmBeforeClose' 
>>>>improvements.
>>>>- Resolved issues with goto-next-clone and goto-next-marked refresh 
>>>>cycles, session management, and body pane labeling.
>>>>- Introduced user-friendly 'Recent Files' icons and buttons.
>>>>
>>>> If you can help to test it and note the bugs you find on the issues 
>>>> page <https://github.com/boltex/leojs/issues>, that'd be great! Join 
>>>> me and the community of Leo enthusiasts in refining LeoJS. Your feedback 
>>>> is 
>>>> invaluable in making LeoJS the best it can be.
>>>>
>>>>  Get Started: LeoJS Beta 0.2.8 
>>>> <https://marketplace.visualstudio.com/items?itemName=boltex.leojs> (also 
>>>> available on open-vsx.org <https://open-vsx.org/extension/boltex/leojs>
>>>> )
>>>>
>>>> *Many thanks to Edward, Thomas Kevin, and the rest of the Leo community 
>>>> for your contributions and support!!*
>>>>
>>>> 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/ce7443f6-8193-4faa-8591-9f56435a7b56n%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

A small point - it would be nice if the release notes mentioned what 
version of VSCode/VSCodium
was needed. I got a message that my version was too old.
(I am running 1.77.1 of VSCodium, will upgrade shortly)

Thanks, jon N

On Tuesday, January 2, 2024 at 9:43:20 AM UTC jkn wrote:

> I like the graphic Felix, well done! ;-)
>
> Jon N
>
> On Tuesday, January 2, 2024 at 3:38:21 AM UTC Félix wrote:
>
>> Introducing LeoJS Beta 0.2.8
>> LeoJS Beta 0.2.8 is here, bringing a substantial update filled with 
>> enhancements and critical fixes.
>> [image: _56d93bdf-e7f0-4625-85a2-cbf3cfc87fee.jpg]
>>
>> What's New in 0.2.8:
>>
>>- *Help Commands*: 'helpCommands.py' was converted to typescript, 
>>enabling help commands.
>>- *UNL Support*: Works in log pane, body panes, and all editor 
>>windows.
>>- *Goto-Script Fix*: Now works seamlessly with @button items.
>>- *Markdown*: The @auto markdown importer and writer now ensures 
>>flawless read-write integrity.
>>- *Undo/Redo for UAs*: Enhanced command support for 'Clear UAs' and 
>>'Set UA'.
>>- *Clone Related Commands*: Fixes to 'show clone ancestors' and 'show 
>>clone parents' commands.
>>- *Workspace-Specific Sessions*: Session management is now more 
>>personalized with workspace-specific settings.
>>- *Stable Node Selection*: LeoJS maintains focus on the selected node 
>>when refreshing external files.
>>- *gnx-kind Setting*: Choose between uuid, ksuid, or traditional GNX.
>>
>>  Continuous Improvements Since Launch:
>>
>>- Refined tooltips, language coloring support, and bug fixes in 
>>various importers.
>>- Enhanced keyboard navigation and pattern support for web browsers.
>>- Streamlined mobile experience, including 'ConfirmBeforeClose' 
>>improvements.
>>- Resolved issues with goto-next-clone and goto-next-marked refresh 
>>cycles, session management, and body pane labeling.
>>- Introduced user-friendly 'Recent Files' icons and buttons.
>>
>> If you can help to test it and note the bugs you find on the issues page 
>> <https://github.com/boltex/leojs/issues>, that'd be great! Join me and 
>> the community of Leo enthusiasts in refining LeoJS. Your feedback is 
>> invaluable in making LeoJS the best it can be.
>>
>>  Get Started: LeoJS Beta 0.2.8 
>> <https://marketplace.visualstudio.com/items?itemName=boltex.leojs> (also 
>> available on open-vsx.org <https://open-vsx.org/extension/boltex/leojs>)
>>
>> *Many thanks to Edward, Thomas Kevin, and the rest of the Leo community 
>> for your contributions and support!!*
>>
>> 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/b2a3bb79-8737-4961-a662-43535f5eeb2fn%40googlegroups.com.

Re: ✨LeoJS beta 0.2.8 Released!

[jkn]

I like the graphic Felix, well done! ;-)

Jon N

On Tuesday, January 2, 2024 at 3:38:21 AM UTC Félix wrote:

> Introducing LeoJS Beta 0.2.8
> LeoJS Beta 0.2.8 is here, bringing a substantial update filled with 
> enhancements and critical fixes.
> [image: _56d93bdf-e7f0-4625-85a2-cbf3cfc87fee.jpg]
>
> What's New in 0.2.8:
>
>- *Help Commands*: 'helpCommands.py' was converted to typescript, 
>enabling help commands.
>- *UNL Support*: Works in log pane, body panes, and all editor windows.
>- *Goto-Script Fix*: Now works seamlessly with @button items.
>- *Markdown*: The @auto markdown importer and writer now ensures 
>flawless read-write integrity.
>- *Undo/Redo for UAs*: Enhanced command support for 'Clear UAs' and 
>'Set UA'.
>- *Clone Related Commands*: Fixes to 'show clone ancestors' and 'show 
>clone parents' commands.
>- *Workspace-Specific Sessions*: Session management is now more 
>personalized with workspace-specific settings.
>- *Stable Node Selection*: LeoJS maintains focus on the selected node 
>when refreshing external files.
>- *gnx-kind Setting*: Choose between uuid, ksuid, or traditional GNX.
>
>  Continuous Improvements Since Launch:
>
>- Refined tooltips, language coloring support, and bug fixes in 
>various importers.
>- Enhanced keyboard navigation and pattern support for web browsers.
>- Streamlined mobile experience, including 'ConfirmBeforeClose' 
>improvements.
>- Resolved issues with goto-next-clone and goto-next-marked refresh 
>cycles, session management, and body pane labeling.
>- Introduced user-friendly 'Recent Files' icons and buttons.
>
> If you can help to test it and note the bugs you find on the issues page 
> , that'd be great! Join me and 
> the community of Leo enthusiasts in refining LeoJS. Your feedback is 
> invaluable in making LeoJS the best it can be.
>
>  Get Started: LeoJS Beta 0.2.8 
>  (also 
> available on open-vsx.org )
>
> *Many thanks to Edward, Thomas Kevin, and the rest of the Leo community 
> for your contributions and support!!*
>
> 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/b2ac665a-d03f-4347-b2c7-41fa1e7f03dcn%40googlegroups.com.

Re: Installing nim was easy!

[jkn]

"nim is both case- and underscore-insensitive"

I had forgotten this when reading about nim some time ago. I know that
first appearances can be deceptive, but hmm...


On Monday, January 1, 2024 at 5:05:00 PM UTC tbp1...@gmail.com wrote:

> How did you install gcc?  Using minGW?
>
> On Monday, January 1, 2024 at 10:27:25 AM UTC-5 Edward K. Ream wrote:
>
>> Apparently the malware warnings are spurious: See nim issue #23151 
>> .
>>
>> That said, there is no way I would open the .zip file without first 
>> disinfecting it.
>>
>> The Nim install page said to 
>> run finish.exe after unpacking the .zip file. But that file does not exist. 
>> Happily, earlier I had found the Nim Package Directory 
>> .
>>
>> I was looking for a python tokenizer, but I noticed the Nim package 
>> .
>>
>> To complete the install I just ran nimble install nim from Nim's bin 
>> directory. Everything just worked!
>>
>> Perhaps I got lucky: I had already installed gcc (and added gcc.cmd) so 
>> nimble could invoke gcc even with gcc missing from my Windows path.
>>
>> *Summary*
>>
>> Use nimble install nim to complete the install.
>>
>> I am eager to start playing with Nim!
>>
>> 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/01047ad1-a35b-405b-a6f2-bdbebfeaead9n%40googlegroups.com.

Re: Does LeoJS have an equivalent to the minibuffer?

[jkn]

Perhaps it is just not normally visible? From 
https://open-vsx.org/extension/boltex/leojs :

"""
   The Minibuffer 
For those 
familiar with Leo, the ‘minibuffer’ serves as the nerve center for command 
execution. Access it through Alt+X and use the complete set of Leo’s 
commands!
"""

On Saturday, December 23, 2023 at 6:15:44 PM UTC tbp1...@gmail.com wrote:

> IOW, how can Leo commands be run if there isn't an ALT-x/minibuffer? I 
> don't see one.  Am I just missing it somehow?

-- 
You received this message because you are subscribed 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/f06f3450-5663-4086-a496-28081b879aa4n%40googlegroups.com.

Re: leoJS Seems To Work With VSCodium

[jkn]

Thanks for the heads up - I too use VSCodium (a bit) and this was the 
version I was hoping to try leoJS with

J^n


On Friday, December 22, 2023 at 8:18:23 PM UTC tbp1...@gmail.com wrote:

> VSCodium is a version of VSCode that does not include Microsoft-specific 
> additions like telemetry.  It's the same code base so everything *ought* to 
> work the same.
>
> I've installed VSCodium, and leoJS seems to be working the same as on 
> VSCode.
>

-- 
You received this message because you are subscribed 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/accdccd9-6f67-4c35-aa63-29dd31f5dc61n%40googlegroups.com.

general thought about Google Groups & Usenet etc.

[jkn]

Hi all
just musing, really ... as many will know, Google are preventing, from 
Feb 2024, content being posted to USENET groups via Google Groups.

For at least some people this will be a disincentive to use USENET groups 
(probably part of their longer term plan).

I realise that leo-editor is *not* a USENET group - it is a 'Google Groups 
group' or something similar. But this change will make it an outlier, at 
least for me. I will probably switch to using the www.eternal-september.org 
USENET server instead of via a browser.

Just musing on whether being tied to Google is a good idea for this forum...

In any case, very best wishes of the season to all on this newsgroup. I ope 
to try out LeoJS over the holiday period...

Regards
J^n

-- 
You received this message because you are subscribed 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/5af18bc7-11a4-4cfa-b347-f1a1166f7c14n%40googlegroups.com.

'resource nodes', eg. for headline icons?

[jkn]

Hi all
a minor itch... 'resource nodes', eg. for headline icons

I am starting to use some of my own custom node icons within Leo. This is 
quite handy do graphically marking different types of 'todo' items.

Currently I am using Inkscape to make a little graphic, then exporting this 
as a .PNG file. I store these external to Leo and use 'insert-icon' to add 
them to a headline

I was wondering a couple of ways of improving this:

- is there any mileage in being able to hold such small .PNG files as 
'resource nodes' within Leo? 
- similarly, is there any mileage in supporting .SVG files/resources for 
node icons?

Thanks, Jon N

-- 
You received this message because you are subscribed 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/9c733801-931b-4cf7-823f-b6e79ad4ec82n%40googlegroups.com.

Re: Problem running Leo after installing Python 3.12

[jkn]

Yes, I've vaguely wondered about Textual (https://www.textualize.io/) as 
well

J^n

On Thursday, October 12, 2023 at 4:24:47 PM UTC+1 map...@gmail.com wrote:

> There is also a problem with Windows-Curses and py 3.12:
> https://github.com/leo-editor/leo-editor/issues/3603
>
> (Hello everyone!)
> On Thursday, October 12, 2023 at 4:12:14 a.m. UTC-7 lewis wrote:
>
>> I have PyQt6 installed but it is v6.5.2
>> See 
>> https://www.riverbankcomputing.com/pipermail/pyqt/2023-October/045542.html
>>
>> On Thursday, October 12, 2023 at 10:03:51 PM UTC+11 Edward K. Ream wrote:
>>
>>
>> Yes, you must install Qt.
>>
>> #3604  suggests 
>> improving this message.
>>
>> 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/ec09a4e1-7f69-47d8-9d62-bc2a420e1da9n%40googlegroups.com.

Re: Moving beyond Leo

[jkn]

Yes, I (like others, I think) came to outline editors, and Leo etc, as part 
or a line that included Knuth's espousal of Literate Programming, tangle 
and weave etc.

Not come across Harmony Assistant before.

On Monday, October 2, 2023 at 8:32:47 PM UTC+1 Edward K. Ream wrote:

> On Sunday, October 1, 2023 at 7:07:05 AM UTC-5 Edward K. Ream wrote:
>
>
> > P.S. Leo got started as a way to understand Knuth's TeX 
>  program.
>
> Phil Straus, who suggested I look into MORE 30+ years ago,  suggests I 
> take a look at Harmony Assistant 
> .
>
> Has anyone used this program?
>
> 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/096be98d-5aea-4563-a23c-be5049de8219n%40googlegroups.com.

Re: Moving beyond Leo

[jkn]

I occasionally use MuseScore to create scores for my granddaughter to play 
on the cornet. Being a TeX fan, I would have liked to use lillypond or 
similar, but it would take me forever and MuseScore is perfectly adequate 
for my purposes(*).

However I rather imagine that the output of Musescore is looked upon with 
polite (or not so polite?) disdain by 'proper' music setters...

(*) and the new owners of MuseScore are trying to monetize it, irritatingly

On Sunday, October 1, 2023 at 10:03:42 PM UTC+1 Edward K. Ream wrote:

> On Sun, Oct 1, 2023 at 3:58 PM jkn  wrote:
>
>> you can definitely lose yourself for years in typography, fontography and 
>> music notation-ography ... fun times...
>>
>
> Indeed.
>
> 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/7499646c-565b-446c-814e-2f1971f17003n%40googlegroups.com.

Re: Moving beyond Leo

[jkn]

you can definitely lose yourself for years in typography, fontography and 
music notation-ography ... fun times...

On Sunday, October 1, 2023 at 1:57:25 PM UTC+1 Edward K. Ream wrote:

> On Sun, Oct 1, 2023 at 7:44 AM Thomas Passin  wrote:
>
>>
>> On Sunday, October 1, 2023 at 8:07:05 AM UTC-4 Edward K. Ream wrote:
>>
>> Last week, I started playing with LaTeX 
>>  for what is known as music 
>> engraving .
>>
>> Music engraving ... if you want a challenge, well, all right then! 
>>
>
> :-) It should be easier than it sounds. There are tools like lilypond 
> and macros like MusiXTEX 
> . As I said, the challenge is finding the 
> easiest pipeline. I hope to help create my music teacher's next book.
>
> 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/a37394a2-f802-4100-8585-cb5a6a106ee2n%40googlegroups.com.

Re: Discuss: remove ctext importer and writer?

[jkn]

I think I only know about it through reading through the importer for 
'ctext'
some time ago and wondering 'where did that format come from'?   ;-)

so I for one have no reason to keep it

J^n

On Wednesday, September 13, 2023 at 5:09:53 PM UTC+1 Edward K. Ream wrote:

> On Wed, Sep 13, 2023 at 10:58 AM Edward K. Ream  wrote:
>
> Does anyone know anything about the ctext file format? Googling ctext 
>> yields no relevant hits.
>>
>
> Hmm. The docstring for the ctext importer class is:
>
> QQQ
> Read/Write simple text files with hierarchy embedded in headlines::
>
> Leading text in root node of subtree
>
> Etc. etc.
>
> ### A level one node #
>
> This would be the text in this level one node.
>
> And this.
>
> ### Another level one node ###
>
> Another one
>
>  A level 2 node ##
>
> See what we did there - one more '#' - this is a subnode.
>
> Leading / trailing whitespace may not be preserved.  '-' and '/'
> are used in place of '#' for SQL and JavaScript.
> QQQ
>
> The docstring might suffice to fix the quirp, but does not explain where 
> this convention came from.
>
> Unless I hear howls of outrage, I'd like to remove support for this 
> bizarre format.
>
> 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/c4446ff2-f10d-44e1-b85d-84d54a86bcecn%40googlegroups.com.

Re: When scripting with Leo, how to call a command by name?

[jkn]

FWIW the current options for doing this have always seemed a bit 
sub-optimal to me, due to the reasons you suggest. 
c.executeMinibufferCommand('name-of-command') seem like the wrong level to 
me, I should be able to call something 'lower down' than this...


On Monday, September 4, 2023 at 4:34:01 AM UTC+1 Félix wrote:

> I agree, respecting existing parameter orders and signatures in general is 
> very important. But making it optional does not interfere with normal 
> usage. 
>
> On Sunday, September 3, 2023 at 11:06:54 PM UTC-4 tbp1...@gmail.com wrote:
>
>> I've never encountered or used that method.  But it's another case where 
>> I would resist changing the signature of an existing command.  If it's only 
>> a matter of making and argument optional, that would be more palatable.  
>> The "events" in question here are not Python things but Leo objects.  They 
>> often carry the "c" parameter, for example, so the command can access it.
>>
>> On Sunday, September 3, 2023 at 9:24:35 PM UTC-4 Félix wrote:
>>
>>> Having in mind a fresh new user's perspective, I wonder if 
>>> *doCommandByName*, *the method with the most intuitive name to use for 
>>> such a task to perform*, could not be relatively easily modified to 
>>> support not having an 'event' passed to it? 
>>>
>>> ...I'm not familiar with those 'events' concepts in python so I'm 
>>> curious about Edwards thought on this matter. 
>>>
>>> Hoping it can be changed easily ! :)
>>>
>>> Félix
>>>
>>> On Sunday, September 3, 2023 at 9:13:39 PM UTC-4 tbp1...@gmail.com 
>>> wrote:
>>>
 There's also c.k.simulateCommand('name-of-command').  I'm not sure why 
 there are both, since they seem to do the same thing.  With either one, 
 you 
 don't need to supply a fake event.  The method takes care of that. I use 
 whichever one I remember first.

 On Sunday, September 3, 2023 at 9:08:31 PM UTC-4 gates...@gmail.com 
 wrote:

> I tend to use c.executeMinibufferCommand('name-of-command') -- doesn't 
> need any extra parameters, and Just Works TM.
>
> Jake
>
> On Sun, Sep 3, 2023 at 8:41 PM Félix  wrote:
>
>> Making script in Leo is great, with the globally defined vars g, c 
>> and p anything is possible. 
>>
>> But what is the recommended way of doing a simple command by name in 
>> a script?
>>
>> The *c.doCommandByName* method exists, but it insists on having an 
>> event as a second parameter. 
>>
>> I discovered that I can make it work by passing a fake event such as 
>> : {"c": c}, or even a better one: g.app.gui.create_key_event(c),  but 
>> this 
>> is quite unintuitive. Could it not default to a valid default event if 
>> the 
>> event is not passed?
>>
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/68b44f92-c2fd-403b-97aa-58fba041d366n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1583b47e-000f-45e8-ac4f-0c0e085fb09en%40googlegroups.com.

Re: ENB: Ahas re paste-retaining-clones

[jkn]

Well, Happy Birthday Edward! ;-)

Regards, Jon N


On Sunday, August 13, 2023 at 10:31:16 AM UTC+1 Edward K. Ream wrote:

> Today is my 74th birthday. This Engineering Notebook post is my birthday 
> present to myself.
>
>
> For the last week, I have been trying to make paste-retaining-clones work. 
> Unit tests show this command improperly computes v.parents arrays in the 
> pasted outline.
>
>
> This morning I saw the way forward:
>
>
> *Aha!* paste-retaining-clones must recompute *all* v.parents arrays in 
> the entire outline!
>
>
> I won't attempt a formal proof, but I am sure this Aha is correct. Note 
> that the paste-node command does *not *require the complications 
> described next.
>
>
> *Recomputing v.parents*
>
>
> But how to recompute v.parents?
>
>
> - We can't use Position generators because they all use v.parents!
> - We can't use VNode generators because they don't yield VNodes in outline 
> order.
>
>
> *Aha! *Define a *c.all_vnode_positions* generator. This *hybrid generator* 
> will 
> yield VNodes in the same order as p.all_positions *using neither 
> v.parents nor Positions.* 
>
>
> Is it possible to write this generator? Yes, it is. The generator will 
> maintain an explicit stack just like Position.stack. *Note*: 
> c.all_vnode_positions must yield the hidden root VNode.
>
>
> *Recomputing all v.parents*
>
>
> Supposing the new generator exists, recomputing all v.parents arrays is 
> straightforward. Something like this (untested):
>
>
> for v in c.all_vnode_positions():
>
> v.parents = []
>
> for v in c.all_vnode_positions():
>
> for child in v.children:
>
> child.parents.append(v)
>
>
> Yes, a one-pass solution is possible. It *might* be faster.
>
>
> *Summary*
>
>
> *Aha!* The paste-retaining-clones command must recompute *all *v.parents 
> ivars. This recomputation is sound. The link correction in 
> c.checkVnodeLinks is not.
>
>
> Leo can use neither Position nor VNode generators to do the recomputation.
>
>
> *Aha!* A new generator, *c.all_vnode_positions*, will yield all VNodes in 
> outline order using neither v.parents nor Positions.
>
>
> Given this generator, updating all v.parents ivars will be straightforward.
>
>
> Edward
>
>
> P.S. Let us define a *hybrid generator *as a generator yielding VNodes in 
> the same order as some Position generator *without *using Positions.
>
>
> Could Leo replace Position generators with hybrids? I think not. For 
> example, please take a look qtree.full_redraw. It would not be fun to 
> eliminate Positions there.
>
>
> In any event, Leo's Position class is never going away :-)
>
>
> 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/667252b3-0580-4a72-ab5e-29154440d1d8n%40googlegroups.com.

Re: Press ⌘ then click node

[jkn]

Yes, three slashes works for me as well, and is 'correct' as a URI.

 I am not quite sure why I thought it was four slashes. I think I worked 
with some app at one point which needed the 'final' slash escaping somehow 
... it might have been related to Windows UNC schemes

Anyway, good to know that it all still works

J^n

On Thursday, July 27, 2023 at 10:19:50 AM UTC+1 lewis wrote:

> file:///path/to/a/file/or/directory 
>
> works on Windows if 3 slashes are used.
>

-- 
You received this message because you are subscribed 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/651c8e11-95a0-4305-9e69-07b9876d6b27n%40googlegroups.com.

Re: Press ⌘ then click node

[jkn]

Yes, this is a very useful feature.

I though we had had discussions about using xdg-open() to open a file 
manager, so that you could also CTRL-click on

file:path/to/a/file/or/directory

and have your file manager come up. That doesn't seem to be working though. 
Maybe I have forgotten something about it...


On Thursday, July 27, 2023 at 4:50:11 AM UTC+1 tbp1...@gmail.com wrote:

> Not just the first line - any line with a recognizable URL should show 
> that URL to be highlighted, and a CTRL-Click (or the Apple equivalent) on 
> the highlighted URL will navigate you to it in the browser. CTRL-Clicking 
> can navigate you to:
>
> - A URL, as above;
> - a node within a Leo outline (by clicking on a highlighted GNX or UNL);
> - A class, method or function definition within the same outline by 
> CTRL-Clicking on it (may not be the definition you want depending on what 
> the search finds first, but it's usually what you want).
> - A << named section >> (CTRL-Click on the section name in a node's body, 
> and Leo will navigate you to its expansion in the outline).
>
> There's probably something else I've forgotten just now.
>
> On Wednesday, July 26, 2023 at 9:05:13 PM UTC-4 iamap...@gmail.com wrote:
>
>> When I was using the features related to Leo and GitHub issues, I 
>> discovered...
>>
>> When the first line of the body of a node contains a URL, you can 
>> conveniently open that URL by pressing ⌘ and clicking the node. Leo boasts 
>> an abundance of hidden features.
>>
>

-- 
You received this message because you are subscribed 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/c469371d-16e6-4213-9ad2-38b646ac5b83n%40googlegroups.com.

Re: Interesting Post on The Old New Thing - Do Nothing At First

[jkn]

That's pretty much TDD, isn't it?


On Tuesday, July 25, 2023 at 4:01:30 PM UTC+1 tbp1...@gmail.com wrote:

> Before you try to do something, make sure you can do nothing 
> 
>

-- 
You received this message because you are subscribed 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/1e724a1c-da27-4d26-b928-11c0e5903954n%40googlegroups.com.

Re: Search for node by GNX with g.findGnx

[jkn]

Hmm - I know there is a smiley here, but ... really?

Seems like a rather tautological approach to code and testing quality to me.

J^n


On Thursday, July 20, 2023 at 5:43:54 PM UTC+1 Edward K. Ream wrote:

> On Thu, Jul 20, 2023 at 9:21 AM Thomas Passin  wrote:
>
>> I'm inclined to agree.
>>
>
> Functions do what they do, regardless of their names or docstrings :-)
>
> If you want to know what they are guaranteed to do, look at their unit 
> tests.
>
> 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/f066032e-3321-49b1-b63a-df95fefdbf2fn%40googlegroups.com.

Re: About undoing commands, especially tree operations

[jkn]

putting Edward's response to the side for now at least, I would like to say 
as a general point that I am always very interested to read anything 
Vitalije writes here.

I seem to remember he has an occasionally-updated blog, i must go and hunt 
that down...

J^n


On Saturday, July 15, 2023 at 6:17:38 AM UTC+1 Edward K. Ream wrote:

> On Fri, Jul 14, 2023 at 5:05 PM vitalije  wrote:
>
> > I don't see how offline data structures help recreate clones. How do 
>> they simulate Leo's low-level VNode operations?
>>
>>
>> In order to see, you have to be willing to look first.
>>
>
> I'm not willing to change Leo's Position and VNode classes in any way.
>
> 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/ea65c40a-c224-4381-8310-c21aad5e9b3fn%40googlegroups.com.

Re: new error: " Bad @data contextmenu_commands entry:"

[jkn]

Hmm - on a different machine which doesn't show the error, I see that the 
equivalent entries in myLeoSettings.py only have a single dash:

@data contextmenu_commands 
copy-node Copy Node
cut-node Cut Node
paste-node Paste Node 
-
insert-node Insert Node
insert-child Insert Child
-
open-url-under-cursor Open URL


So it looks like this is the correct format to use.

OTOH I am pretty sure I haven't seen the other error before, on that 
machine. Maybe error mesages have been improved?

Apologies if it turns out this is just noise...

Regards, Jon N


On Monday, July 10, 2023 at 7:45:50 AM UTC+1 jkn wrote:

> I'm noticing this when leo loads, I am pretty sure I have not seen this 
> before:
>
> repeated several times:
> Bad @data contextmenu_commands entry: ['---']
>
>
> I think this is coming from my myLeoSettings.leo, which has 
>
>
> @data contextmenu_commands 
>
> copy-node Copy Node
> cut-node Cut Node
> paste-node Paste Node 
> ---
> insert-node Insert Node
> ---
>open-url-under-cursor Open URL
>
>
> (NB: only two separators, not three)
>
>
> Has something changed here recently? Maybe just the error message?...
>
>
> Thanks
>
> J^n
>
>
>
> Leo Log Window
> Leo 6.7.4-devel, devel branch, build 103f5c5e1e
> 2023-07-09 09:20:05 -0500
> Python 3.9.5, 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/1372a36a-9790-408d-ba7b-4dd7e0cc4ce5n%40googlegroups.com.

new error: " Bad @data contextmenu_commands entry:"

[jkn]

I'm noticing this when leo loads, I am pretty sure I have not seen this 
before:

repeated several times:
Bad @data contextmenu_commands entry: ['---']


I think this is coming from my myLeoSettings.leo, which has 


@data contextmenu_commands 

copy-node Copy Node
cut-node Cut Node
paste-node Paste Node 
---
insert-node Insert Node
---
   open-url-under-cursor Open URL


(NB: only two separators, not three)


Has something changed here recently? Maybe just the error message?...


Thanks

J^n



Leo Log Window
Leo 6.7.4-devel, devel branch, build 103f5c5e1e
2023-07-09 09:20:05 -0500
Python 3.9.5, 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/ad3b3d55-0f27-40f1-8c2d-6c66e99710ben%40googlegroups.com.

Re: The big PR did remove some gui-related code

[jkn]

I mentioned it, in the thread "Ctrl-Click on gnx fails if the node is dirty?
"

On Saturday, July 8, 2023 at 1:14:56 AM UTC+1 Edward K. Ream wrote:

> There was some discussion (I don't remember where) about a weird edge 
> case: changing a clickable link and then undoing the change *without* saving 
> the file caused Leo not to find the clickable link.
>
> I dismissed this nit as likely unrelated to the big PR. However, I now see 
> that the *full_match* helper function (internal to g.findUNL) *did* 
> contain gui code. Imo removing that code was correct, but there is a chance 
> that doing so created problems.
>
> *Summary*
>
> This post sets the record straight, but I have no intention of restoring 
> the old code.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b006e8c5-b7c3-4d74-849f-c4d0551ca505n%40googlegroups.com.

Re: Aha: no need for a new paste command

[jkn]

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

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

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

J^n



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

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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/809cc8a9-077e-4238-8084-683ee6e82963n%40googlegroups.com.

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

[jkn]

Thomas' list sounds pretty sensible to me at first blush. Nevertheless, I 
do wonder whether keeping things in a discussion/proposal phase for a while 
would be a good idea, rather than (for instance) jumping onto #3429.

J^n


On Thursday, July 6, 2023 at 6:40:33 PM UTC+1 Edward K. Ream wrote:

> On Thu, Jul 6, 2023 at 11:09 AM Thomas Passin  wrote:
>
> I propose that whether a node gets cut or copied, that [snip].
>>
>
> Many thanks for this great idea. 
>
> See #3429 . I'll do 
> this asap. 
>
> 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/ac3811e4-cfb9-423c-ad72-ae35dfd12a4cn%40googlegroups.com.

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

[jkn]

So, "once you have learned about gnx's, Cut- and paste- nodes is lost to 
you"?

Sorry, like Jake says, I am trying to be constructive here. But I too think 
things are moving too fast.

Jon N


On Thursday, July 6, 2023 at 2:49:17 PM UTC+1 Edward K. Ream wrote:

> On Thu, Jul 6, 2023 at 8:02 AM Thomas Passin  wrote:
>
>> The gnx change  may be expected, but as a user if I cut a node and paste 
>> it somewhere else, in my mind it's the *same* node and an "unbreakable" UNL 
>> should take me to that same node afterwards.  In my mind there should be no 
>> difference between moving a node using move commands (like CTRL-D) and 
>> moving it by cut-paste.  
>>
>> I would say that a user who has not thought about, or maybe not even 
>> learned about, gnx's would not expect a unl to break when he did a 
>> cut-paste on a node.
>>
>
> The average Leonista may cut and paste nodes without harm. Leo's devs *must 
> never *do so.
>
> Clear?
>
> 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/aeaa7753-767e-4a50-aa2b-de6b385a00f5n%40googlegroups.com.

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

[jkn]

Hi Edward
  By  'devs', do you mean, erm ... 'users' ?

I agree with Thomas, I think there is a real disagreement here.

Has it always been true that "Leo devs should *never* move nodes by 
copy/paste", or is this a recent ... limitation, or ... evolution of your 
thinking, or what?

Thanks, Jon N

On Thursday, July 6, 2023 at 2:21:11 PM UTC+1 Edward K. Ream wrote:

> On Thursday, July 6, 2023 at 8:11:56 AM UTC-5 jkn wrote:
>
> What are Outline | Cut-Node and Outline | Paste-Node for then?
>
>
> An earlier reply 
> <https://groups.google.com/g/leo-editor/c/JH4Au0F0vjk/m/-zdr4xVHAwAJ> (in 
> this thread) explains that "copy outline" creates an independent copy.
> Useful for cherry-picking nodes from other branches.
>
> A later reply 
> <https://groups.google.com/g/leo-editor/c/JH4Au0F0vjk/m/G7poknJJAwAJ> (in 
> this thread) explains why *Leo devs should never move nodes by copy/paste*
> .
>
> 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/8af538a5-6e77-4953-8cde-93c7824045d9n%40googlegroups.com.

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

[jkn]

On Thursday, July 6, 2023 at 1:45:21 PM UTC+1 Edward K. Ream wrote:

On Wed, Jul 5, 2023 at 11:21 PM Thomas Passin  wrote:

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


Then don't move nodes by cut and paste!


really?!

What are Outline | Cut-Node and Outline | Paste-Node for then?


I *never* move nodes this way. Surely you can find an alternative that 
works for 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/fa5b96e2-14cf-428a-96cd-25b44cc2fde4n%40googlegroups.com.

Re: Why gnx-based unls are important

[jkn]

How does the current scheme address the situation of two identically-named 
files in different directories?


On Wednesday, July 5, 2023 at 7:41:12 PM UTC+1 Edward K. Ream wrote:

> On Wed, Jul 5, 2023 at 12:14 PM Thomas Passin  wrote:
>
> > I don't think the concept of operations for the new UNLs has been fully 
> worked out yet.
>
> I know of no problems whatsoever with gxn-based unls.
>
> Leo's new link-resolution code significantly improves the operation of 
> legacy (path-based) links/unls.
>
> Please comment in PR #3424 
>  if you have a *specific 
> *complaint. 
>
> 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/fdf3e46d-8367-41e5-8eb4-c469c79988f8n%40googlegroups.com.

Ctrl-Click on gnx fails if the node is dirty?

[jkn]

Whilst experimenting with the new gnx work just now (I will add a posting 
to the relevant thread soon, I hope) I came across the following strange 
behaviour. No idea if it is old or new.

1) pasted a unl:gnx reference into a node
2) Ctrl-LCclick on it: confirm you go to the right node(*)
3) go back to the first node and 'mess with' the reference, eg. by adding 
some text to the end of the unl:gnx reference(**)
4) delete the text you just added but do not save the file; the node is 
'dirty'
5) ctrl-LClick on the reference again
   I get taken to entirely different node, with no relation to the actual 
one!

6) if you write the file, then the Ctrl-LClick seems to work as expected

(*) separate point: this seems to take me to the end of the node body. Is 
that alterable?
(**) I was experimenting with changing (*) here when I saw this behaviour

Regards
J^n

-- 
You received this message because you are subscribed 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/e690016a-f83d-4145-83b1-7c9742efda90n%40googlegroups.com.

Re: Why gnx-based unls are important

[jkn]

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

(*) 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

Sorry if this is muddying the waters...

Jon N



On Wednesday, July 5, 2023 at 12:00:35 PM UTC+1 Edward K. Ream wrote:

> This post explains why PR #3215 
> <https://github.com/leo-editor/leo-editor/pull/3215> (gnx-based unls) is 
> a milestone in Leo's history.
>
>
> gnx-based unls are a fundamental resource comparable in importance to 
> @clean and cff:
>
>
> - Unls won't break if you rename or move a node.
>
> - Leo supports *platform-independent* cross-file unls.
>
> - Creating gnx-based unls is dead easy.
>
>
> Leo now contains significant new resources related to gnx-based unls:
>
>
> *@data unl-path-prefixes* helps resolve unls to different paths on 
> different platforms. *Most users need to know only about this setting.*
>
>
> Leo provides two other resources for plugins:
>
>
> *g.parsePathData* parses such @data nodes to a python dict.
>
>
> *g.openUNLFile(c, s)* resolves s (the file part of an unl) to a 
> commander, defaulting to c if no resolution is possible. This function 
> contains an Easter Egg. It will return c immediately if s specifies the 
> active outline.
>
>
> Plugins can monkey-patch g.openUNLFile to gain *complete *control over 
> how Leo resolves unls.
>
>
> *Summary*
>
>
> gnx-based unls are a fundamental resource comparable in importance to 
> `@clean` and cff. Creating unbreakable cross-file unls is dead easy.
>
>
> Leonistas will likely find creative new uses for unls. For example, a 
> script could scan a document, possibly contained in different outlines, 
> converting unls to links for markup/reStructuredText.
>
>
> Most users need to know only about the *@data unl-path-prefixes* setting. 
> *g.parsePathData* parses such @data nodes to a python dict.
>
>
> Plugins can monkey-patch *g.openUNLFile* to gain complete control over 
> how Leo resolves unls.
>
>
> All of your questions and comments are welcome.
>
>
> Edward
>
>
> P.S. Plugins can also alter @data unl-path-prefixes *programmatically *by 
> calling *c.config.set*. Like this:
>
>
> c.config.set(kind='data', name='unl-path-prefixes', val=lines)
>
>
> Unit tests for leoGlobals do this using *LeoUnitTest._set_setting*. Take 
> a look :-)
>
>
> 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/95912f6e-c907-4b72-9ede-b75e91ef8eb6n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

[jkn]

FWIW I usually run Leo from a direct desktop shortcut - having different 
command files to run with different command-line parameters is something 
... unusual. I only ever do it if I have had a crash and am trying to see 
what is going on. Having a series of batch/sh files seems very ... 1990s to 
me...

On Friday, June 30, 2023 at 3:01:24 PM UTC+1 Edward K. Ream wrote:

> On Fri, Jun 30, 2023 at 8:53 AM jkn wrote:
>
> The idea, n*ow fully realized* in PR #3215 
>> <https://github.com/leo-editor/leo-editor/pull/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).
>>
>>
>> That sounds reasonable enough. Might it be worth making (1) alterable via 
>> an @setting variable?
>>
>
> I'd rather not :-)
>
>> I can just see some scenario where you have a usual set of sessions 
>> saved, but want to have a 'scratch' session with a different set, or just 
>> one file or something.
>>
>
> Well, the "usual set" implies that a script file would work. For example, 
> I use scripts with names like 'e' (my personal outline), 't' (test.leo', 
> 'd' (LeoDocs.leo) and 's' (leoPy.leo).
>
> Yes. I *could* just always type 'leo', but that's two too many letters!
>
>> FWIW I rarely use session-snapshot-load, just when I change my 'default' 
>> session setup. So I would no longer need to do this.
>>
>
> As you say, there is a very slight advantage to doing session save/load 
> manually, but I don't think the advantage is worth yet another setting!
>
> I'll attempt to give this a try soon.
>>
>
> Great. Please tell us about your experience.
>
> 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/ec48f512-d370-4470-b848-23ec815b9d09n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

[jkn]

Hi Edward

On Friday, June 30, 2023 at 1:41:08 PM UTC+1 Edward K. Ream wrote:

On Fri, Jun 30, 2023 at 5:04 AM jkn  wrote:

FWIW I can't really tell what #3408 will actually *do*. "Real Sessions" 
sounds great, but what is written there is more about the coding. I would 
like to better understand when the user experience will be at the end of 
this.


The idea, n*ow fully realized* in PR #3215 
<https://github.com/leo-editor/leo-editor/pull/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).


That sounds reasonable enough. Might it be worth making (1) alterable via 
an @setting variable?

I can just see some scenario where you have a usual set of sessions saved, 
but want to have a 'scratch' session with a different set, or just one file 
or something.

FWIW I rarely use session-snapshot-load, just when I change my 'default' 
session setup. So I would no longer need to do this.

I'll attempt to give this a try soon.

Thanks
Jon


 

This scheme is what I understand to be real sessions. It's not *exactly* 
equivalent to *manually *doing session-snapshot-load because Leo always 
overwrites the previously saved session.

Please try this all out.

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/32075821-dc0a-4fa9-9252-d9cf7b6e4958n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

[jkn]

FWIW I can't really tell what #3408 will actually *do*. "Real Sessions" 
sounds great, but what is written there is more about the coding. I would 
like to better understand when the user experience will be at the end of 
this.

(sorry if I seem like an ungrateful consumer of terrific free SW).

FWIW, conversation titles like 'The SessionManager will go away' probably 
cause people to go "what?! Why?! When?!", which might not be what you 
want...

Jon N


On Friday, June 30, 2023 at 10:39:52 AM UTC+1 jkn wrote:

> starting Leo via different sets of (for me) .sh files, for different 
> 'session sets of files' seems pretty cheesy in this day & age - sorry.
>
> I haven't yet taken a look at #3408, I will do so asap.
>
> Thanks, Jon N
>
>
> On Friday, June 30, 2023 at 9:20:54 AM UTC+1 Edward K. Ream wrote:
>
>> On Friday, June 30, 2023 at 3:12:44 AM UTC-5 Edward K. Ream wrote:
>>
>> > Would #3408 <https://github.com/leo-editor/leo-editor/issues/3408> 
>> work for you? In effect, #3404 would do these commands automatically.
>>
>> If "fluid" sessions don't work for you the obvious workflow is to create 
>> .sh/.cmd files starting Leo with specified sets of outlines.
>>
>> session-snapshot-load and session-snapshot-save can only ever save *one* 
>> set of outlines, so these two commands are much less flexible than .sh/.cmd 
>> files.
>>
>> 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/8d3636bf-8016-48a0-9f1f-90a9a07c055fn%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

[jkn]

starting Leo via different sets of (for me) .sh files, for different 
'session sets of files' seems pretty cheesy in this day & age - sorry.

I haven't yet taken a look at #3408, I will do so asap.

Thanks, Jon N


On Friday, June 30, 2023 at 9:20:54 AM UTC+1 Edward K. Ream wrote:

> On Friday, June 30, 2023 at 3:12:44 AM UTC-5 Edward K. Ream wrote:
>
> > Would #3408  work 
> for you? In effect, #3404 would do these commands automatically.
>
> If "fluid" sessions don't work for you the obvious workflow is to create 
> .sh/.cmd files starting Leo with specified sets of outlines.
>
> session-snapshot-load and session-snapshot-save can only ever save *one* 
> set of outlines, so these two commands are much less flexible than .sh/.cmd 
> files.
>
> 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/ac71360f-7dce-49ce-8a5c-27ef7daf60b3n%40googlegroups.com.

Re: Heads up: The SessionManager class will go away

[jkn]

I'm not 100% clear what the revised functionality you propose would be ... 
but as one of (the) main people who requested some sort of session 
management, a few years back, I would strongly dislike losing this feature.

I routinely start Leo with a set of files (four or five), previously saved 
via session-snapshot-load and session-snapshot-save. Unless I'm 
misunderstanding you, loss of this feature would be a serious blow to my 
leo productivity.

Jon N


On Friday, June 30, 2023 at 8:45:17 AM UTC+1 Edward K. Ream wrote:

> On Thursday, June 29, 2023 at 5:06:37 PM UTC-5 Edward K. Ream wrote:
>
> 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 :-)
>
>
> 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 :-)
>
>
> Thanks to all who have commented.
>
>
> Yes, Leo could have "real" sessions. When no files appear on the command 
> line, Leo could reload the open outlines when Leo last closed. Issue #3408 
>  tells how. It's 
> easy! It's on the list for Leo 6.7.4.
>
>
> But nothing in leoSessions.py gives Leo such sessions. The SessionManager 
> class and the session-* commands must go.
>
>
> 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/f9a5d001-a2a7-499e-af3a-e498677f55abn%40googlegroups.com.

Re: Heads Up - My Workbook Is Getting Destroyed

[jkn]

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.

J^n

On Wednesday, June 28, 2023 at 4:42:37 PM UTC+1 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.
>
> 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/816faed6-426b-415b-976c-8988282e14edn%40googlegroups.com.

Re: Code Review, Requirements, and Community Particiation

[jkn]

I'm not going to go too far down this rabbit hole - I have a day job - but 
in general I would agree that 'too tricky to understand' code is a red flag.

On Monday, June 26, 2023 at 8:34:47 PM UTC+1 tbp1...@gmail.com wrote:

> In the announcement about the proposed PR 3215 that massively affects 
> UNLs, @Edward wrote
>
> "I won't wait for a code review. The code involved is too tricky to 
> understand in an hour or five."
>
> This statement contains two red flags. If it's too tricky for a code 
> review, there's something out of whack somewhere.  The answer isn't to skip 
> code review, it's to figure out how to make it more accessible so that it 
> *can* be commented on and reviewed.
>
> One important aspect of that is having requirements.  If we had a proposed 
> set of requirements for a change to fix a well-defined problem, we probably 
> wouldn't be in the fix we're in right now about this PR.  The Leo community 
> could have commented on the requirements and perhaps suggested changes.  
> True, I seem to be the only part of the community that has responded, but 
> maybe others would have.
>
> Then changes could have proposed and it could be explained how they would 
> work to satisfy the requirements.  And once that all seemed all right, then 
> tests could have ben written, the details could have been implemented and 
> tested.
>
> I'm not suggesting that written requirements would be needed for minor 
> changes or bug fixes.  But for something which is too complicated to 
> review?  And without requirements, you can't really write proper tests, 
> either  The way it has worked in this case, the "requirements" live in one 
> person's head, are not very well specified, and are subject to rapid 
> change.  (I'm like that, too! But sometimes, I do write requirements just 
> for myself.)
>
> Yes, it might have taken longer to formulate some requirements and let the 
> community digest and comment on them.  But there was no need for speed.  
> The impetus for this was not a critical bug.  There was no need to rush 
> major, breaking changes.
>
> If I had seen some requirements, I would have asked to add one similar to 
> this -
>
> *Backwards Compatibility*
> 1. Existing UNL-consuming code shall work without changes.
> 2. CTRL-Click navigation to legacy UNLs shall continue to work 
> correctly.
> 3. The status bar shall continue to display a representation of the 
> path to the selected node.
>
> Now, maybe item 1. wouldn't be possible.  Then we could have had a 
> discussion about why not, and how to handle using the new UNLs with 
> existing functions.  We could have changed that requirement to make it 
> clear what was supposed to be accomplished.  If we had a sketch of proposed 
> changes, we could have seen where method signatures were changed, and if 
> that had been intended or a mistake.
>
> All this would have made Felix's life easier, too!  And I imagine that he 
> would have had some good input to contribute.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ab80e178-958f-4400-a5ab-090b3de90ccdn%40googlegroups.com.

Re: leojs alpha

[jkn]

Hi Félix

Thanks for the extra information. That does sound like a lot of work, I 
(too) am impressed with your dedication. But I agree with Thomas that 
maintaining two codebases in sync is probably and impossible job in 
practice.

I would kinda-hate Leo to end up as a javascript (/typescript) app instead 
of a Python one ... but I am also very interested in seeing the results. I 
will try to be a beta tester for you ;-)

Regards, J^n

On Monday, June 26, 2023 at 7:14:36 PM UTC+1 Félix wrote:

> Hi jkn! :D
>
> Thanks for your interest and questions! 
>
> I've translated/transliterated (not sure which is appropriate!) about 99% 
> myself manually, and I've used chatGPT for small parts (e.g. some regular 
> expressions, some small quirky methods) which I would estimate to be 1% of 
> the code. (anyways - from 2021 to early 2023 chatGPT did not even exist!)
>
> Even then, the parts translated with AI had to be manually inspected and 
> tested. (I've played a lot with chatGPT translations from python to 
> typescript and it does not account for subtle details in some "almost 
> identical" native functions, which inevitably break the intended behavior) 
> In fact, the more important and subtle a detail is, the more likely it is 
> that AI will ignore it. (which may even compile and run in normal cases, 
> but break in edge/extreme cases)
>
> For example, regex (Leo uses those a lot in critical places) have subtle 
> differences in the usage of 'flags' such as 'm' or 'g' in python vs 
> javascript, which will totally fail if not taken into account.
>
> So it's really risky to use AI for translation. (if not thoroughly 
> inspected and tested) 
>
> About the 'upstream' work on Leo - I did the oldest, less likely to change 
> code first. Also, I have not done the importers yet, nor the unl support, 
> which happen to be re-written or changed in the last few weeks hehe !
>
>  For other stuff that changed, I try to keep up by collaborating with 
> Edward to change Leojs & match Leo's changes as quickly as possible, as to 
> not fall to much behind.
>
> I look in the commit history and diffs with tools in gitlens (vscode 
> extension) to keep up with the changes and modify leojs as much as possible.
>
> I usually work on implementing stuff for 2-3 weeks ,and then spend a week 
> to catch up with what was updated by Edward (if it happens to be on stuff 
> already in leojs). 
>
> Thanks for your support and curiosity! Best to you - Hope you'll be 
> testing & reporting bugs when I release the first beta in a few days (or 
> weeks)!  ;)
>
> Félix
>
>
> On Monday, June 26, 2023 at 10:09:17 AM UTC-4 jkn wrote:
>
>> Hi Felix - something I've missed in the exciting mentions re. leojs here. 
>> Is the 'transliteration' done manually ('after coding for a few years'...) 
>> or via some (semi'?)-automated process?
>>
>> If the former, I'm wondering how 'upstream' work on Leo gets 
>> incorporated. If the latter, I'm curious about the process...
>>
>> Thanks & Regards, J^n
>>
>>
>> On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:
>>
>>> Thanks Arjan!! 
>>>
>>> Simple encouragements and feedback means a lot to me!
>>>
>>> Félix 
>>>
>>> On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
>>>
>>>> > After coding for a few years
>>>>
>>>> Awesome perseverance. I've just continued using regular Leo because I'm 
>>>> used to the workflow, but I hope to find some time to play with the newer 
>>>> developments. Good luck!
>>>>
>>>> On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
>>>>
>>>>> > ...So anywhere from a week or two, or a month or two, hard to say, 
>>>>> but it's going to be this summer! :D
>>>>>
>>>>> Assuming vs-code allows it, I encourage you to release an alpha 
>>>>> version asap. There is nothing wrong with a list of known bugs.
>>>>>
>>>>> Edward
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/bcddcf31-b89e-4235-9608-9b3484ba9c46n%40googlegroups.com.

Re: leojs alpha

[jkn]

Hi Felix - something I've missed in the exciting mentions re. leojs here. 
Is the 'transliteration' done manually ('after coding for a few years'...) 
or via some (semi'?)-automated process?

If the former, I'm wondering how 'upstream' work on Leo gets incorporated. 
If the latter, I'm curious about the process...

Thanks & Regards, J^n


On Sunday, June 25, 2023 at 7:47:30 PM UTC+1 Félix wrote:

> Thanks Arjan!! 
>
> Simple encouragements and feedback means a lot to me!
>
> Félix 
>
> On Sunday, June 25, 2023 at 9:03:39 AM UTC-4 Arjan wrote:
>
>> > After coding for a few years
>>
>> Awesome perseverance. I've just continued using regular Leo because I'm 
>> used to the workflow, but I hope to find some time to play with the newer 
>> developments. Good luck!
>>
>> On Thursday, June 22, 2023 at 1:08:48 PM UTC+2 Edward K. Ream wrote:
>>
>>> > ...So anywhere from a week or two, or a month or two, hard to say, but 
>>> it's going to be this summer! :D
>>>
>>> Assuming vs-code allows it, I encourage you to release an alpha version 
>>> asap. There is nothing wrong with a list of known bugs.
>>>
>>> Edward
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a18dde03-fcf3-461d-af01-e91985fa78cfn%40googlegroups.com.

Re: About PR #3215: unbreakable unls!

[jkn]

Yes, I was a bit surprised this wasn't your approach as well. Looking 
forward to the results regardless...


On Sunday, June 25, 2023 at 5:49:36 PM UTC+1 tbp1...@gmail.com wrote:

> 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/bfd2fee7-7792-45b8-8964-ff18881d4ac9n%40googlegroups.com.

Re: An RPN Calculator For Leo

[jkn]

As a slight aside: I knew about the 'bc' (bench calculator) program in 
Linux/Unix, and I also knew there was a 'dc' (desk calculator) in Linux/Unix

What I didn't realise, and have only just learned, is:

* dc is the original and runs RPN
* dc predates the C programming language; it is the oldest surviving Unix 
program, and Ken Thompson has opined that it was the first one written (in 
B) for the PDP-ll running Unix
* the BC program is written on top of dc.

https://en.wikipedia.org/wiki/Dc_(computer_program)


On Tuesday, May 2, 2023 at 11:04:55 AM UTC+1 Edward K. Ream wrote:



On Tue, May 2, 2023 at 4:35 AM jkn  wrote:

s/write/right/, of course ;-o


Hehe.  I remember *screaming* in frustration while using some nerdy 
sed-like text editor while working at IBM 50+ years ago. My work on editors 
began with those screams.

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/91d10dcb-eaaa-4594-8cb8-d26651f75746n%40googlegroups.com.

Re: two comma presses == no change?!

[jkn]

fantastic - my efficiency will skyrocket!

On Thursday, May 11, 2023 at 3:00:48 PM UTC+1 Edward K. Ream wrote:

> On Thu, May 11, 2023 at 7:52 AM Rob  wrote:
>
>> If, for some reason I might need 2 commas in succession, my workaround is 
>> to type `, ,` (inserted space between commas). 
>
>
> Or type one comma, backspace, and type the other comma :-)
>
> 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/e9a61e99-5296-4a96-ad09-9c878a6d3125n%40googlegroups.com.

Re: two comma presses == no change?!

[jkn]

I do the same. The occurrence is rare enough that I am surprised when I 
encounter the original behaviour - at the moment I treat it as an amusing 
quirk ...

On Thursday, May 11, 2023 at 1:52:32 PM UTC+1 Rob wrote:

> If, for some reason I might need 2 commas in succession, my workaround is 
> to type `, ,` (inserted space between commas). Then I simply backspace and 
> delete the space character. The only time I have actually done this is to 
> document my abbreviations. HTH
>
> Rob...
>
> On Tuesday, May 9, 2023 at 7:18:58 AM UTC-4 jkn wrote:
>
>> I'm more curious than anything...
>>
>> If I press the comma ',' key twice in succession, the first character 
>> placed in the body text by the first press, gets deleted on the second 
>> press!
>>
>> I don't know of any setting, command, or abbreviation that I have that 
>> might be causing this - any thoughts?
>>
>> Thanks, J^n
>>
>

-- 
You received this message because you are subscribed 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/21b9781a-9b1d-454d-8107-a4c874350d1fn%40googlegroups.com.

Re: two comma presses == no change?!

[jkn]

Ah, right, thanks - that makes sense.

I think you are right that it should only happen when expanding 
abbreviations, but I can live with it - I was just curious...

Regards
J^n


On Tuesday, May 9, 2023 at 12:39:12 PM UTC+1 Edward K. Ream wrote:

> On Tue, May 9, 2023 at 6:19 AM jkn  wrote:
>
> If I press the comma ',' key twice in succession, the first character 
>> placed in the body text by the first press, gets deleted on the second 
>> press!
>
>
> See @string abbreviations-next-placeholder = ,,
>
> Arguably the behavior you describe should only happen when expanding 
> abbreviation.
>
> 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/4f4c96f9-a1e9-4e02-885c-581a87619dcfn%40googlegroups.com.

two comma presses == no change?!

[jkn]

I'm more curious than anything...

If I press the comma ',' key twice in succession, the first character 
placed in the body text by the first press, gets deleted on the second 
press!

I don't know of any setting, command, or abbreviation that I have that 
might be causing this - any thoughts?

Thanks, J^n

-- 
You received this message because you are subscribed 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/0ae6caaa-a3b3-43f5-a9d0-065e5628e46cn%40googlegroups.com.

Re: ENB: Won't do: pep 8 names

[jkn]

On Friday, May 5, 2023 at 11:10:59 PM UTC+1 tbp1...@gmail.com wrote:

On Friday, May 5, 2023 at 6:01:33 PM UTC-4 Edward K. Ream wrote:

On Fri, May 5, 2023 at 3:24 PM jkn  wrote:

https://peps.python.org/pep-0008/

"This document gives coding conventions for the Python code *comprising the 
standard library* in the main Python distribution"


Pep 8 contains many caveats and subtle points. I don't want to debate those 
:-)

The mixture of camelCase and underscore_case does sometimes upset newbies, 
but I think most of us agree that we can't change names.

PEP-8 goes on to say -

"... code is read much more often than it is written. The guidelines 
provided here are intended to improve the readability of code and make it 
consistent across the wide spectrum of Python code. As PEP 20 
<https://peps.python.org/pep-0020> says, “Readability counts”."

And

"In particular: do not break backwards compatibility just to comply with 
this PEP!

Some other good reasons to ignore a particular guideline:

   1. When applying the guideline would make the code less readable, even 
   for someone who is used to reading code that follows this PEP.
   2. To be consistent with surrounding code that also breaks it (maybe for 
   historic reasons) – although this is also an opportunity to clean up 
   someone else’s mess (in true XP style).
   3. Because the code in question predates the introduction of the 
   guideline and there is no other reason to be modifying that code.
   4. When the code needs to remain compatible with older versions of 
   Python that don’t support the feature recommended by the style guide." 


BTW, have you (anyone) tried the easter egg?

import this


Ah, the Zen of Python. Last time I did was about  fifteen years ago ;-o


-- 
You received this message because you are subscribed 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/c9f56c7c-d1a9-4072-ab62-c5aad8e37335n%40googlegroups.com.

Re: ENB: Won't do: pep 8 names

[jkn]

I've mentioned this before, but note the wording at beginning of PEP-8:

https://peps.python.org/pep-0008/

"This document gives coding conventions for the Python code *comprising the 
standard library* in the main Python distribution"

*emphasis* mine.



On Friday, May 5, 2023 at 2:36:23 PM UTC+1 Edward K. Ream wrote:

> On Fri, May 5, 2023 at 8:22 AM Thomas Passin  wrote:
>
>> +1!
>>
>
> :-) I've considered this several times. Apparently I need constant 
> reminding that this is not a clever idea!
>
> 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/c44ff77a-5b65-4882-8f65-23b20b409bd4n%40googlegroups.com.

Re: Pyspread - a spreadsheet where each cell can be a Python expression

[jkn]

Yea, I know Michael Foord's (at least) writing and work on Python from 
quite a while ago. I had forgotten the link with IronPython, thanks.

On Tuesday, May 2, 2023 at 7:04:07 PM UTC+1 David Szent-Györgyi wrote:

> On Tuesday, May 2, 2023 at 1:04:27 PM UTC-4 jkn wrote:
>
> There was a much older 'python in a spreadsheet' program, created by 
> Resolver Systems. I followed it with interest, they tried to create a 
> commercial product out of it but failed.
>
>
> That product used IronPython - an alternate implementation of Python 
> implemented on the Dynamic Language Runtime for .NET 
> <https://ironpython.net>. Resolver Systems is long gone, but IronPython 
> is still out there, though development by its tiny team is slow - the 
> current release added Python3 features, and was released early in 2023; it 
> is closest to CPython 3.4. 
>
> Unlike CPython, IronPython has no Global Interpreter Lock ("GIL"), and it 
> used unicode for strings long before that was sorted out in CPython. 
> Differences between IronPython and CPython make IronPython a dialect, but  
> one well-suited to multi-threaded projects. It is an excellent "glue 
> language" as it is an interpreter with a JIT compiler; it has full access 
> to .NET  as well as to Win32; it also has access to libraries accessible 
> through CTypes. In my day job, I write complex macros in IronPython for an 
> application that controls exotic hardware; I prefer the IronPython 
> read-eval-print-loop to compiling code through a heavyweight IDE and 
> compiler that Get In My Way. 
>
> Michael Foord and Christian Muirhead, who were with Resolver Systems, 
> wrote an excellent book on IronPython 
> <https://www.manning.com/books/ironpython-in-action>. While its content 
> has not been updated to address the current release, its exploration of 
> .NET specifics makes it worth reading for the newcomer to IronPython. 
>
>

-- 
You received this message because you are subscribed 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/1b05843d-6eba-42a0-8761-bc95b8a95be4n%40googlegroups.com.

Re: Pyspread - a spreadsheet where each cell can be a Python expression

[jkn]

There was a much older 'python in a spreadsheet' program, created by 
Resolver Systems. I followed it with interest, they tried to create a 
commercial product out of it but failed.

IIRC pyspread is much less ambitious than Resolver, but it might be that it 
is more successful because of that. I still with the beta version or 
whatever of the Resolver Systems one was available though.

On Tuesday, May 2, 2023 at 10:46:16 AM UTC+1 Edward K. Ream wrote:

> On Mon, May 1, 2023 at 5:51 PM Thomas Passin  wrote:
>
>> I just learned about Pyspread , which is a 
>> spreadsheet program where cells contain Python expressions or code.  They 
>> can also contain images, which makes it interesting to see how the image 
>> data is stored and used.  It's a PyQt program, so there might be some good 
>> lessons to learn.
>
>
> I agree.
>
> 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/34bc49c8-efe1-46c3-88a0-c87c9bf8f3afn%40googlegroups.com.

Re: An RPN Calculator For Leo

[jkn]

s/write/right/, of course ;-o

On Tuesday, May 2, 2023 at 9:50:53 AM UTC+1 jkn wrote:

> FWIW I sometime use the underscore character in a 'down' sense. So R_ , 
> perhaps.
>
> I used to write a fair bit in (La)TeX, and that uses caret ^ for 
> superscript, and underscore _ for subscript, so it 'feels' write to me...
>
> J^n
>
> On Monday, May 1, 2023 at 8:18:33 PM UTC+1 tbp1...@gmail.com wrote:
>
>> Much better!  I'll change it soon.  BTW, I'm sorry about *R>* for "Roll 
>> Down".  The original code used *R<* and *R>*, apparently because we 
>> don't have up and down arrows on a normal keyboard (well, speaking for US 
>> English keyboards, anyway).  I changed the one to a caret (*R^*) but 
>> there's no similar down symbol one can type.  I could have used a unicode 
>> arrow but it can't be typed conveniently.  The way the code works, if you 
>> type the string on a button (some of them, anyway) it activates the same 
>> command as if you had clicked on its button.
>>
>> On Monday, May 1, 2023 at 2:22:05 PM UTC-4 jkn wrote:
>>
>>> Shurely that should be called >CLIP  ? ;-)
>>>
>>> On Monday, May 1, 2023 at 5:46:45 PM UTC+1 tbp1...@gmail.com wrote:
>>>
>>>> Devel now contains one more change.  I've changed the *EXIT* key 
>>>> (which isn't needed in the Leo tab version of the calculator) to 
>>>> *TOCLIP*. It copies the "X" register - the calculation result - to the 
>>>> system clipboard.
>>>>
>>>> On Monday, May 1, 2023 at 9:31:00 AM UTC-4 Thomas Passin wrote:
>>>>
>>>>> When I was using TurboPascal and doing a lot of numerical 2-D 
>>>>> integrations with complex numbers, I actually wrote a little library 
>>>>> module 
>>>>> to calculate with complex numbers as if I was using an RPN calculator.  
>>>>> So 
>>>>> you could push a complex number on the stack, pop it off, multiply or add 
>>>>> the two numbers on the stack bottom, etc.  At that time TurboPascal did 
>>>>> not 
>>>>> have complex numbers of its own, IIRC.  If N1 and N2 were two complex 
>>>>> numbers you could write, for example (based on hazy memories from long 
>>>>> ago):
>>>>>
>>>>> push(N1)
>>>>> push(N2)
>>>>> CMul()
>>>>> { and so forth, pun intended }
>>>>>
>>>>> I enjoyed using the library because it was so easy for me to write and 
>>>>> debug calculations.  I just pictured how I would do the calculation on my 
>>>>> HP calculator and walked through the steps.  I timed it once, and the 
>>>>> extra 
>>>>> overhead of using the stack library compared with a hand-crafted sequence 
>>>>> of operations was about 25% (I'm sure my implementation could have been 
>>>>> improved, it was pretty brute-force).  But the ease of writing the 
>>>>> calculation and debugging it - the RPN library won hands down.
>>>>>
>>>>> On Monday, May 1, 2023 at 9:02:49 AM UTC-4 jkn wrote:
>>>>>
>>>>>> I got to play with a then- just out Hewlett Packard HP-67 RPN 
>>>>>> calculator at the age of around 14. It blew my mind ... and may well 
>>>>>> have 
>>>>>> directly led to me doing what I do to this day.
>>>>>>
>>>>>> J^n
>>>>>>
>>>>>> On Sunday, April 30, 2023 at 5:59:34 PM UTC+1 tbp1...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>>> RPCalc is a recent discovery for me. As originally written, it runs 
>>>>>>> as a standalone program, and requires Qt5.  You don't need to use the 
>>>>>>> installer package for Windows.  Just download the Linux tarball, 
>>>>>>> decompress 
>>>>>>> it, and navigate to the "source" directory.  The file to run is - 
>>>>>>> surprise! 
>>>>>>> - rpcalc.py.  It seems to do everything I want from an RPN calculator, 
>>>>>>> except that copying the stack bottom is awkward.
>>>>>>>
>>>>>>> To adapt it for Leo, one change was to combine all the source files 
>>>>>>> into one Leo @file tree.  Another was to change the imports to use 
>>>>>>> leoQt, 
>>>>>>> which makes it easier to adapt to Qt5 vs Qt6, and anyway is essential

Re: An RPN Calculator For Leo

[jkn]

FWIW I sometime use the underscore character in a 'down' sense. So R_ , 
perhaps.

I used to write a fair bit in (La)TeX, and that uses caret ^ for 
superscript, and underscore _ for subscript, so it 'feels' write to me...

J^n

On Monday, May 1, 2023 at 8:18:33 PM UTC+1 tbp1...@gmail.com wrote:

> Much better!  I'll change it soon.  BTW, I'm sorry about *R>* for "Roll 
> Down".  The original code used *R<* and *R>*, apparently because we don't 
> have up and down arrows on a normal keyboard (well, speaking for US English 
> keyboards, anyway).  I changed the one to a caret (*R^*) but there's no 
> similar down symbol one can type.  I could have used a unicode arrow but it 
> can't be typed conveniently.  The way the code works, if you type the 
> string on a button (some of them, anyway) it activates the same command as 
> if you had clicked on its button.
>
> On Monday, May 1, 2023 at 2:22:05 PM UTC-4 jkn wrote:
>
>> Shurely that should be called >CLIP  ? ;-)
>>
>> On Monday, May 1, 2023 at 5:46:45 PM UTC+1 tbp1...@gmail.com wrote:
>>
>>> Devel now contains one more change.  I've changed the *EXIT* key (which 
>>> isn't needed in the Leo tab version of the calculator) to *TOCLIP*. It 
>>> copies the "X" register - the calculation result - to the system clipboard.
>>>
>>> On Monday, May 1, 2023 at 9:31:00 AM UTC-4 Thomas Passin wrote:
>>>
>>>> When I was using TurboPascal and doing a lot of numerical 2-D 
>>>> integrations with complex numbers, I actually wrote a little library 
>>>> module 
>>>> to calculate with complex numbers as if I was using an RPN calculator.  So 
>>>> you could push a complex number on the stack, pop it off, multiply or add 
>>>> the two numbers on the stack bottom, etc.  At that time TurboPascal did 
>>>> not 
>>>> have complex numbers of its own, IIRC.  If N1 and N2 were two complex 
>>>> numbers you could write, for example (based on hazy memories from long 
>>>> ago):
>>>>
>>>> push(N1)
>>>> push(N2)
>>>> CMul()
>>>> { and so forth, pun intended }
>>>>
>>>> I enjoyed using the library because it was so easy for me to write and 
>>>> debug calculations.  I just pictured how I would do the calculation on my 
>>>> HP calculator and walked through the steps.  I timed it once, and the 
>>>> extra 
>>>> overhead of using the stack library compared with a hand-crafted sequence 
>>>> of operations was about 25% (I'm sure my implementation could have been 
>>>> improved, it was pretty brute-force).  But the ease of writing the 
>>>> calculation and debugging it - the RPN library won hands down.
>>>>
>>>> On Monday, May 1, 2023 at 9:02:49 AM UTC-4 jkn wrote:
>>>>
>>>>> I got to play with a then- just out Hewlett Packard HP-67 RPN 
>>>>> calculator at the age of around 14. It blew my mind ... and may well have 
>>>>> directly led to me doing what I do to this day.
>>>>>
>>>>> J^n
>>>>>
>>>>> On Sunday, April 30, 2023 at 5:59:34 PM UTC+1 tbp1...@gmail.com wrote:
>>>>>
>>>>>> RPCalc is a recent discovery for me. As originally written, it runs 
>>>>>> as a standalone program, and requires Qt5.  You don't need to use the 
>>>>>> installer package for Windows.  Just download the Linux tarball, 
>>>>>> decompress 
>>>>>> it, and navigate to the "source" directory.  The file to run is - 
>>>>>> surprise! 
>>>>>> - rpcalc.py.  It seems to do everything I want from an RPN calculator, 
>>>>>> except that copying the stack bottom is awkward.
>>>>>>
>>>>>> To adapt it for Leo, one change was to combine all the source files 
>>>>>> into one Leo @file tree.  Another was to change the imports to use 
>>>>>> leoQt, 
>>>>>> which makes it easier to adapt to Qt5 vs Qt6, and anyway is essential if 
>>>>>> the program is to run in a Leo frame.  I'm still finding little things 
>>>>>> that 
>>>>>> aren't working for both Qt5 and Qt6 - mostly enums and flags - but I'm 
>>>>>> making progress. But overall, most of the functionality works and the 
>>>>>> thing 
>>>>>> is usable as it stands.  I'll post an updated outline soon, and after 
>>>>>> some 
>>>>

Re: An RPN Calculator For Leo

[jkn]

Shurely that should be called >CLIP  ? ;-)

On Monday, May 1, 2023 at 5:46:45 PM UTC+1 tbp1...@gmail.com wrote:

> Devel now contains one more change.  I've changed the *EXIT* key (which 
> isn't needed in the Leo tab version of the calculator) to *TOCLIP*. It 
> copies the "X" register - the calculation result - to the system clipboard.
>
> On Monday, May 1, 2023 at 9:31:00 AM UTC-4 Thomas Passin wrote:
>
>> When I was using TurboPascal and doing a lot of numerical 2-D 
>> integrations with complex numbers, I actually wrote a little library module 
>> to calculate with complex numbers as if I was using an RPN calculator.  So 
>> you could push a complex number on the stack, pop it off, multiply or add 
>> the two numbers on the stack bottom, etc.  At that time TurboPascal did not 
>> have complex numbers of its own, IIRC.  If N1 and N2 were two complex 
>> numbers you could write, for example (based on hazy memories from long ago):
>>
>> push(N1)
>> push(N2)
>> CMul()
>> { and so forth, pun intended }
>>
>> I enjoyed using the library because it was so easy for me to write and 
>> debug calculations.  I just pictured how I would do the calculation on my 
>> HP calculator and walked through the steps.  I timed it once, and the extra 
>> overhead of using the stack library compared with a hand-crafted sequence 
>> of operations was about 25% (I'm sure my implementation could have been 
>> improved, it was pretty brute-force).  But the ease of writing the 
>> calculation and debugging it - the RPN library won hands down.
>>
>> On Monday, May 1, 2023 at 9:02:49 AM UTC-4 jkn wrote:
>>
>>> I got to play with a then- just out Hewlett Packard HP-67 RPN calculator 
>>> at the age of around 14. It blew my mind ... and may well have directly led 
>>> to me doing what I do to this day.
>>>
>>> J^n
>>>
>>> On Sunday, April 30, 2023 at 5:59:34 PM UTC+1 tbp1...@gmail.com wrote:
>>>
>>>> RPCalc is a recent discovery for me. As originally written, it runs as 
>>>> a standalone program, and requires Qt5.  You don't need to use the 
>>>> installer package for Windows.  Just download the Linux tarball, 
>>>> decompress 
>>>> it, and navigate to the "source" directory.  The file to run is - 
>>>> surprise! 
>>>> - rpcalc.py.  It seems to do everything I want from an RPN calculator, 
>>>> except that copying the stack bottom is awkward.
>>>>
>>>> To adapt it for Leo, one change was to combine all the source files 
>>>> into one Leo @file tree.  Another was to change the imports to use leoQt, 
>>>> which makes it easier to adapt to Qt5 vs Qt6, and anyway is essential if 
>>>> the program is to run in a Leo frame.  I'm still finding little things 
>>>> that 
>>>> aren't working for both Qt5 and Qt6 - mostly enums and flags - but I'm 
>>>> making progress. But overall, most of the functionality works and the 
>>>> thing 
>>>> is usable as it stands.  I'll post an updated outline soon, and after some 
>>>> more work it should be ready to appear in the Leo repo.
>>>>
>>>> On Sunday, April 30, 2023 at 11:55:06 AM UTC-4 jkn wrote:
>>>>
>>>> I have wondered about suggesting something like this for a while, so 
>>>> thank you Thomas. My 'main' editor has a simple HP calculator built into 
>>>> it 
>>>> and it was an easy step to consider one for Leo.
>>>>
>>>> I didn't know about RPNCalc (I have some Android RPN apps on my phone, 
>>>> as well as a real HP-35s), but it sounds like a good choice.
>>>>
>>>>
>>>>  I've used HP RPN calculators since way back in HP-45 days.  I 
>>>> liked the HP-25C even better, and finally ended up using an HP-15C.  Mine 
>>>> still works though it's slightly misplaced just now.  On my computer I've 
>>>> been using Free42, which seems to me to be a good balance between 
>>>> readability, complexity, and capability.  Now it looks like RPCalc will be 
>>>> taking over from Free42.
>>>>  
>>>>
>>>> I will take a look at this shortly - thanks.
>>>>
>>>>  J^n
>>>>
>>>>
>>>> On Sunday, April 30, 2023 at 12:03:14 PM UTC+1 Edward K. Ream wrote:
>>>>
>>>> On Sat, Apr 29, 2023 at 12:42 PM Thomas Passin  
>>>> wrote:
>>>>
>>>> I have adapted the open-source *RPCalc* c

Re: An RPN Calculator For Leo

[jkn]

I got to play with a then- just out Hewlett Packard HP-67 RPN calculator at 
the age of around 14. It blew my mind ... and may well have directly led to 
me doing what I do to this day.

J^n

On Sunday, April 30, 2023 at 5:59:34 PM UTC+1 tbp1...@gmail.com wrote:

> RPCalc is a recent discovery for me. As originally written, it runs as a 
> standalone program, and requires Qt5.  You don't need to use the installer 
> package for Windows.  Just download the Linux tarball, decompress it, and 
> navigate to the "source" directory.  The file to run is - surprise! - 
> rpcalc.py.  It seems to do everything I want from an RPN calculator, except 
> that copying the stack bottom is awkward.
>
> To adapt it for Leo, one change was to combine all the source files into 
> one Leo @file tree.  Another was to change the imports to use leoQt, which 
> makes it easier to adapt to Qt5 vs Qt6, and anyway is essential if the 
> program is to run in a Leo frame.  I'm still finding little things that 
> aren't working for both Qt5 and Qt6 - mostly enums and flags - but I'm 
> making progress. But overall, most of the functionality works and the thing 
> is usable as it stands.  I'll post an updated outline soon, and after some 
> more work it should be ready to appear in the Leo repo.
>
> On Sunday, April 30, 2023 at 11:55:06 AM UTC-4 jkn wrote:
>
> I have wondered about suggesting something like this for a while, so thank 
> you Thomas. My 'main' editor has a simple HP calculator built into it and 
> it was an easy step to consider one for Leo.
>
> I didn't know about RPNCalc (I have some Android RPN apps on my phone, as 
> well as a real HP-35s), but it sounds like a good choice.
>
>
>  I've used HP RPN calculators since way back in HP-45 days.  I liked 
> the HP-25C even better, and finally ended up using an HP-15C.  Mine still 
> works though it's slightly misplaced just now.  On my computer I've been 
> using Free42, which seems to me to be a good balance between readability, 
> complexity, and capability.  Now it looks like RPCalc will be taking over 
> from Free42.
>  
>
> I will take a look at this shortly - thanks.
>
>  J^n
>
>
> On Sunday, April 30, 2023 at 12:03:14 PM UTC+1 Edward K. Ream wrote:
>
> On Sat, Apr 29, 2023 at 12:42 PM Thomas Passin  wrote:
>
> I have adapted the open-source *RPCalc* calculator to run in a tab in the 
> Leo log frame.  This calculator is a Reverse Polish Notation (RPN) style 
> calculator, which IMHO is much better than the  algebraic-entry type.  It 
> is the type of calculator that Hewlett-Packard made famous.
>
>
> Thanks for this work, Thomas. The calculator appears as expected for me. 
>
> PR #3301 <https://github.com/leo-editor/leo-editor/pull/3301> is a draft 
> containing the files you mention. It's a good start. The PR lists three 
> 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/ab706ad5-fcb4-474d-a0df-5b47485a1b93n%40googlegroups.com.

Re: An RPN Calculator For Leo

[jkn]

I have wondered about suggesting something like this for a while, so thank 
you Thomas. My 'main' editor has a simple HP calculator built into it and 
it was an easy step to consider one for Leo.

I didn't know about RPNCalc (I have some Android RPN apps on my phone, as 
well as a real HP-35s), but it sounds like a good choice.

I will take a look at this shortly - thanks.

 J^n


On Sunday, April 30, 2023 at 12:03:14 PM UTC+1 Edward K. Ream wrote:

> On Sat, Apr 29, 2023 at 12:42 PM Thomas Passin  wrote:
>
> I have adapted the open-source *RPCalc* calculator to run in a tab in the 
>> Leo log frame.  This calculator is a Reverse Polish Notation (RPN) style 
>> calculator, which IMHO is much better than the  algebraic-entry type.  It 
>> is the type of calculator that Hewlett-Packard made famous.
>
>
> Thanks for this work, Thomas. The calculator appears as expected for me. 
>
> PR #3301  is a draft 
> containing the files you mention. It's a good start. The PR lists three 
> 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/4f03d6e3-7761-493e-978a-2b7f583b98dbn%40googlegroups.com.

Re: Dropping a file vs importing it: @edit vs @auto

[jkn]

I have been meaning to check this for ages - what happens if you try to 
drag and drop a .leo file into a running leo?

looks like you have to drop it into the tree pane, and it then becomes one 
of the open .leo files - cool

and if you try to drag and drop a non-leo file (into the tree pane) it gets 
turned into an @file node.

Good, I think...

J^n




On Wednesday, April 19, 2023 at 4:38:58 PM UTC+1 tbp1...@gmail.com wrote:

> Well, it's not *too* mysterious.  When you drop the file its path gets 
> added to the command line that the OS uses to launch Leo (or whatever 
> program the desktop icon is for).
>
> On Wednesday, April 19, 2023 at 10:43:49 AM UTC-4 Edward K. Ream wrote:
>
>> On Wed, Apr 19, 2023 at 9:04 AM Thomas Passin  wrote:
>>
>> If there is a Leo shortcut on the desktop and you drag and drop a non-Leo 
>>> file on it, an instance of Leo will start and contain an @edit node for the 
>>> dropped file (a .cmd file will be put into an @file node).
>>>
>>> If you import the same file, it will get imported into an @auto subtree.
>>>
>>> Why the difference, and shouldn't both ways do the same thing?
>>>
>>
>> Heh. I didn't know that I could drag and drop as you describe. Here are 
>> some other ways of importing files:
>>
>> -  The import-file command calls *c.importAnyFile*. This method contains 
>> various special cases. Maybe some of those cases are dubious.
>> - Create an empty @ node and do *refresh-from-disk*.
>> - Create an @button node to do exactly as you please with 
>> *c.recursiveImport.*
>>
>> I don't think consistency between these ways is all that important.
>>
>> 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/a8249f47-f8d7-4b71-9283-4f99e95c8005n%40googlegroups.com.

Re: VR3 can now be opened in a tab

[jkn]

To be fair, many/most modern editors have some sort of 'find definition' 
and 'find references' feature

On Sunday, April 9, 2023 at 1:50:50 PM UTC+1 tbp1...@gmail.com wrote:

> Yes:
>
> log = c.frame.log
> g.es(log.orderedTabNames())
>
> BTW, here's how I found this.  I certainly didn't remember, and you may 
> have a better way.  Start with the script for your button. It calls a 
> method log.deleteTab.  In Leo's core code, similar methods are generally 
> grouped together under the same parent node.  So I used the Nav tab - my 
> favorite for searches - and typed in "deleteTab".  It returned two 
> headlines that matched, one of which was "LeoLog.deleteTab".  I clicked on 
> that entry and was navigated to that part of the code.  Then I just scanned 
> the other names until I noticed "LeoLog.orderedTabNames".  That was it.
>
> I usually find this to be the most effective way to proceed.  Sometimes 
> you don't get a hit on a method or class definition but you find a place 
> that it is called.  You can CTRL-click on its name in the code and Leo will 
> (usually) succeed at navigating you to its *def: *or *class: *definition.
>
> Now that I've gotten used to working this way, I don't know how I could 
> stand going back to non-Leo ways of managing of code bases.
> On Sunday, April 9, 2023 at 7:22:19 AM UTC-4 lewis wrote:
>
>> I use an @button Delete-TAB
>>
>> TAB_name = g.app.gui.runAskOkCancelStringDialog(c,'Delete TAB',"Enter 
>> Tab name: ").strip()
>> c.frame.log.deleteTab(TAB_name)  # delete named Tab
>>
>> Is there a way to get a list of Tab names?
>> On Sunday, April 9, 2023 at 12:28:45 AM UTC+10 tbp1...@gmail.com wrote:
>>
>>> Yes, as long as you know its name, which you do from its label:
>>>
>>> log.deleteTab(TABNAME)
>>>
>>> On Saturday, April 8, 2023 at 10:26:30 AM UTC-4 jkn wrote:
>>>
>>>> This look interesting, thanks.
>>>>
>>>> One thing I have never really needed, but occasionally wondered about; 
>>>> it is possible to *delete* a tab in the log pane? (perhaps it should be 
>>>> called the 'tab pane'?...)
>>>>
>>>> J^n
>>>>
>>>> On Friday, April 7, 2023 at 3:04:48 PM UTC+1 tbp1...@gmail.com wrote:
>>>>
>>>>> The VR3 plugin can now optionally open in a tab in the log pane 
>>>>> instead of in its own panel in the main Leo window (also referred to as a 
>>>>> pane in the splitter).  I have attached a screen shot that shows the 
>>>>> panel 
>>>>> layout that I like when using VR3 in a tab.
>>>>>
>>>>> There are two new commands to control that tab behavior:
>>>>>
>>>>> vr3-tab -- opens VR3 in a tab
>>>>> vr3-toggle-tab -- opens or closes VR3 in a tab.
>>>>>
>>>>> I like to use an @button node in the @settings tree to make a button 
>>>>> for vr3-toggle-tab. The button runs
>>>>>  c.k.simulateCommand('vr3-toggle-tab').
>>>>>
>>>>> vr3-toggle will close VR3 if open in a splitter pane as well as in a 
>>>>> tab.  Next time, the command will open it in the splitter.  Conversely, 
>>>>> vr3-toggle-tab will close VR3 in either a tab or the splitter, but 
>>>>> will re-open it in a tab the next time the command is run.
>>>>>
>>>>> An advantage to running VR3 in a tab is that you can open something 
>>>>> else in a new splitter pane without interfering with VR3.
>>>>>
>>>>> One minor drawback is that focus will switch to the log pane when 
>>>>> something is written there - most likely when the outline has been saved. 
>>>>>  
>>>>> Then you have to click in the VR3 tab to see it again.  I haven't found 
>>>>> this to bother me much.
>>>>>
>>>>> This new behavior has now been merged into the devel branch, so it's 
>>>>> ready to try out.
>>>>>
>>>>

-- 
You received this message because you are subscribed 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/23ecd3dd-3f67-4a78-ab05-f5c9e0324651n%40googlegroups.com.

Re: Eye surgery tommorrow

[jkn]

Best Wishes from me also

Jon N

On Wednesday, April 12, 2023 at 11:50:24 AM UTC+1 lewis wrote:

> Best wishes, hope it goes well.
>
>

-- 
You received this message because you are subscribed 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/ae9460bc-7390-485a-8dd2-32c50c240018n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

[jkn]

- shurely '~' is not always needed (if that is what you are saying): I can 
use {{sep}}home{{sep}}myusername{{sep}}tmp{{sep}}filename.txt  , for example
- I really hope you don't choose '*' for such a feature. might something 
like '~~' work?


On Saturday, April 8, 2023 at 3:38:04 PM UTC+1 Edward K. Ream wrote:

> On Saturday, April 8, 2023 at 8:01:11 AM UTC-5 tbp1...@gmail.com wrote:
>
> Leo already handles "~", so we don't need "{{~}}".  
>
>
> Now that I've gathered my wits, let me try to make a simpler response:
>
> 1. The new code (PR #3264 
> ) will be *exactly 
> *equivalent 
> to the old unless an @file headline contains a path expression.
>
> 2. `~' is needed in path expressions unless Leo *already* handles `~/x` 
> or `~/../y` *without* path expressions.
>The PR contains a strong new unit test. I'll test Leo's legacy 
> operation using that test and report back.
>
> 3. *New*: withing path expressions, some character, say '*', will 
> evaluate to (say)
>   os.environment[LEO_BASE_DIRECTORY],
> eliminating the need for conditional code or other hacks.
>
> 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/eca390a6-a444-4204-96ac-151d46aaead0n%40googlegroups.com.

Re: VR3 can now be opened in a tab

[jkn]

I meant at the user level - right-click on a tab or similar... I 
occasionally have tabs 'outstay their welcome' (as in, I don't need their 
content any more)


On Saturday, April 8, 2023 at 3:28:45 PM UTC+1 tbp1...@gmail.com wrote:

> Yes, as long as you know its name, which you do from its label:
>
> log.deleteTab(TABNAME)
>
> On Saturday, April 8, 2023 at 10:26:30 AM UTC-4 jkn wrote:
>
>> This look interesting, thanks.
>>
>> One thing I have never really needed, but occasionally wondered about; it 
>> is possible to *delete* a tab in the log pane? (perhaps it should be called 
>> the 'tab pane'?...)
>>
>> J^n
>>
>> On Friday, April 7, 2023 at 3:04:48 PM UTC+1 tbp1...@gmail.com wrote:
>>
>>> The VR3 plugin can now optionally open in a tab in the log pane instead 
>>> of in its own panel in the main Leo window (also referred to as a pane in 
>>> the splitter).  I have attached a screen shot that shows the panel layout 
>>> that I like when using VR3 in a tab.
>>>
>>> There are two new commands to control that tab behavior:
>>>
>>> vr3-tab -- opens VR3 in a tab
>>> vr3-toggle-tab -- opens or closes VR3 in a tab.
>>>
>>> I like to use an @button node in the @settings tree to make a button for 
>>> vr3-toggle-tab. The button runs c.k.simulateCommand('vr3-toggle-tab').
>>>
>>> vr3-toggle will close VR3 if open in a splitter pane as well as in a 
>>> tab.  Next time, the command will open it in the splitter.  Conversely, 
>>> vr3-toggle-tab will close VR3 in either a tab or the splitter, but will 
>>> re-open it in a tab the next time the command is run.
>>>
>>> An advantage to running VR3 in a tab is that you can open something else 
>>> in a new splitter pane without interfering with VR3.
>>>
>>> One minor drawback is that focus will switch to the log pane when 
>>> something is written there - most likely when the outline has been saved.  
>>> Then you have to click in the VR3 tab to see it again.  I haven't found 
>>> this to bother me much.
>>>
>>> This new behavior has now been merged into the devel branch, so it's 
>>> ready to try out.
>>>
>>

-- 
You received this message because you are subscribed 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/8d9f4d00-0618-4303-a96c-4afb99117ad7n%40googlegroups.com.