date:20230408

PR #3264  fixes a 
security blunder by eliminating support for path expressions of the form:

  {{python statements}}

As compensation, the PR supports Python's *standard syntax* defined by 
os.path.expanduser and os.path.expandvars.

Those who now use path expressions must replace them with the standard 
syntax. A global search/replace should suffice.

This PR will be the highlight of Leo 6.7.3, scheduled for a few days from 
now.  Please test this PR and report any problems.

Edward

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

Re: Discuss: what should path expressions contain?



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/228be406-0dda-4d3f-9481-09fa75e34101n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

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.

On Saturday, April 8, 2023 at 5:53:36 PM UTC-4 Edward K. Ream wrote:

> On Sat, Apr 8, 2023 at 1:50 PM Thomas Passin  wrote:
>
> 1. I don't see any need to use the expression "{{~}}". Just using "~" 
>> works now.
>>
>
> Thomas, you have just opened my eyes. Python should do all the work!
>
> - os.path.expandvars 
>  
> substitutes environment variables!
> - os.path.expanduser 
>  
> handles per-platform resolution of `~`.
> See the links above for details.
>
> As before, any path can be relative to the outline. Just "finalize" the 
> resulting path using:
>
> os.path.normpath(os.path.join(os.path.dirname(c.fileName()), path))
>
> *Summary*
>
> c.expand_path_expression should let os.path do all the work. No more 
> security woes.
>
> There is no need for path expressions! Bye-bye {{ and }}. No more 
> Leo-only conventions.
>
> c.expand_path_expression will collapse.
>
> 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/19a7d837-d1f8-4c3f-80a8-76343e6b3b71n%40googlegroups.com.

Re: Leo 6.7.3 coming soon

On Saturday, April 8, 2023 at 12:13:36 PM UTC-5 Edward K. Ream wrote:

> I shall release Leo 6.7.3 as soon as possible after we test PR #3264 
.

*Aha* (Thanks, Thomas): Python's os.path 
 module contains all the 
tools Leonistas will ever need. Leo can *easily* apply all the os.path 
conventions to all paths of @ nodes.

os.path can expand os.environ constants, so Leo can *easily *replace $name 
or ${name} by the value of environment variable *name*. 

No need to invent Leo-only conventions! No need for path expressions! 
Bye-bye {{ and }}.

Leo's documentation will give examples of using os.path. Like: @file 
$PROJECT_A_BASE/x.py.

> Those who use path expressions should do a global search/replace (on 
headlines).

Still true, but the revised @ nodes will be safe, standard, and 
likely simpler.

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/6cbfac61-a5df-4829-99b2-52daf475246cn%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Sat, Apr 8, 2023 at 1:50 PM Thomas Passin  wrote:

1. I don't see any need to use the expression "{{~}}". Just using "~" works
> now.
>

Thomas, you have just opened my eyes. Python should do all the work!

- os.path.expandvars

substitutes environment variables!
- os.path.expanduser
 handles
per-platform resolution of `~`.
See the links above for details.

As before, any path can be relative to the outline. Just "finalize" the
resulting path using:

os.path.normpath(os.path.join(os.path.dirname(c.fileName()), path))

*Summary*

c.expand_path_expression should let os.path do all the work. No more
security woes.

There is no need for path expressions! Bye-bye {{ and }}. No more Leo-only
conventions.

c.expand_path_expression will collapse.

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/CAMF8tS179BCozd18vNgQ1r5w%3DMWXTmiBNZcKCF-HuDcnq2UQ6w%40mail.gmail.com.

Re: Discuss: what should path expressions contain?


On Saturday, April 8, 2023 at 2:50:01 PM UTC-4 Thomas Passin wrote:

Then I could write, for example:
@file {{leoDir}}/plugins/new_plugin.py
@file ~/.leo/themes/tbp_new_theme.leo  # or {{homeLeoDir}}/themes/
tbp_new_theme.leo


Well, I wouldn't be having a Leo outline in an @file node, I suppose 
[blushes].  Here's a more realistic example:

@clean ~/.leo/vr3/rst-dark.css 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1505b9aa-b9db-4d2b-9f50-5a492bc8c809n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

The current PR says this:

  '!' sets the directory to g.app.loadDir.
'~' sets the directory to os.path.expanduser('~')
'*' sets the directory to os.environ['LEO_BASE_DIRECTORY'] or
os.path.expanduser('~') if the environment variable does not 
exist.

1. I don't see any need to use the expression "{{~}}". Just using "~" works 
now - no need to change it, IMHO.  It would add visual clutter for no 
benefit.
2. I'd like to see mnemonic symbols.  For example: 

{{loadDir}}
{{LEOBASE}}

While we're at it, let's have all the symbolic Leo directories available -

g.app.homeDir #C:/Users/tom
g.app.homeLeoDir #C:/Users/tom/.leo
g.app.leoDir #c:/Tom/git/leo-editor/leo
g.app.loadDir #c:/Tom/git/leo-editor/leo/core
g.app.extensionsDir #c:/Tom/git/leo-editor/leo/extensions
g.app.testDir #c:/Tom/git/leo-editor/leo/test

Then I could write, for example:

@file {{leoDir}}/plugins/new_plugin.py
@file ~/.leo/themes/tbp_new_theme.leo  # or {{homeLeoDir}}/themes/
tbp_new_theme.leo

This would be very easy to read, write, and understand, and would be easy 
to implement.  Visual clutter would be at a minimum.

3. I'd like to add an alias for *loadDir* - *leoCoreDir*. It's more 
mnemonic.  I'm never sure I remember what *loadDir* means.
On Saturday, April 8, 2023 at 2:24:24 PM UTC-4 Edward K. Ream wrote:

> On Saturday, April 8, 2023 at 1:17:31 PM UTC-5 tbp1...@gmail.com wrote:
>
> "*" is so widely used as a wildcard for any string that it would be 
> confusing to use it in another way.
>
>
> Alright. What *single* character would you prefer?
>
> 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/a1d1c88d-1f73-4b92-9cc3-23f8e6653b4dn%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Saturday, April 8, 2023 at 1:17:31 PM UTC-5 tbp1...@gmail.com wrote:

"*" is so widely used as a wildcard for any string that it would be 
confusing to use it in another way.


Alright. What *single* character would you prefer?

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/b189c025-bc78-4dd4-991d-4e65b4b50630n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Saturday, April 8, 2023 at 10:49:03 AM UTC-5 jkn wrote:

I can use {{sep}}home{{sep}}myusername{{sep}}tmp{{sep}}filename.txt


Without understanding  the exactly what you want to do, you probably should 
be able to specify this somehow, either without using path expressions at 
all, or with something like the following: 

   {{~}}tmp/filename.txt
  {{*}}filename.txt
 
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/a6ff4df8-fb58-4ae7-83d3-44d173f47243n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

"*" is so widely used as a wildcard for any string that it would be 
confusing to use it in another way.

On Saturday, April 8, 2023 at 2:13:41 PM UTC-4 Edward K. Ream wrote:

On Saturday, April 8, 2023 at 10:49:03 AM UTC-5 jkn wrote:

- I really hope you don't choose '*' for such a feature. 


What's wrong with *?  I'm willing to use any single character. What would 
you prefer, and why? 

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/332137b3-48c5-4e58-b8ca-bd50786be46an%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Saturday, April 8, 2023 at 10:49:03 AM UTC-5 jkn wrote:

- I really hope you don't choose '*' for such a feature. 


What's wrong with *?  I'm willing to use any single character. What would 
you prefer, and why? 

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/701abe08-087a-4b4d-ade6-646a47a4d6a3n%40googlegroups.com.

Leo 6.7.3 coming soon

I shall release Leo 6.7.3 as soon as possible after we test PR #3264 
. I urge Félix to 
release a new version of leoInteg that will require 6.7.3.

I am horrified that nobody has noticed the security holes in path 
expressions and even more horrified that vs-code seems oblivious.

The security hole is intolerable on a platform like vs-code with millions 
of users.

Those who path expressions should do a global search/replace (on 
headlines). I apologize for the inconvenience.

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/ad1eb548-a963-4ae6-9595-e795f3ef3c00n%40googlegroups.com.

Re: VR3 can now be opened in a tab

I've been thinking they could be given a close box.  I've not looked in to 
what it would take, though.

On Saturday, April 8, 2023 at 10:44:09 AM UTC-4 jkn wrote:

> 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/bd21ca42-b882-48ab-a328-adb5d668dfdcn%40googlegroups.com.

Re: Discuss: what should path expressions contain?

- 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: Discuss: what should path expressions contain?

On Sat, Apr 8, 2023 at 9:39 AM Thomas Passin  wrote:

We definitely need to have a transition strategy so we don't kill anyone's
> existing outlines.


No such strategy is possible.

> Maybe it can be enabled by a setting that initially will have the value
> True but in later releases defaults to False:
>
> @bool use-old-path-expressions = False
>

Absolutely not. The PR *must* break outlines containing path expressions.

The result will (usually) be that Leo can't write the external file, and
Leo will say so.

Edward

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

Re: VR3 can now be opened in a tab

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.

Re: Discuss: what should path expressions contain?

We definitely need to have a transition strategy so we don't kill anyone's 
existing outlines.  I see two ways to approach this:

1. Only allow certain g. methods, all of which would be new and only used 
in path expressions.  Eventually, only these would be allowed.

2. Current path expressions can use curly braces. If there are any places 
we will need them, change them to be, e.g., square brackets for the new 
code.   That will let the path expression code know unambiguously when to 
use the new or the old processing.

Either way, users need to be informed that at some point, the old handling 
will go away.  Maybe it can be enabled by a setting that initially will 
have the value True but in later releases defaults to False:

@bool use-old-path-expressions = False

On Saturday, April 8, 2023 at 10:20:58 AM UTC-4 Edward K. Ream wrote:

> On Sat, Apr 8, 2023 at 8:01 AM Thomas Passin  wrote:
>
> Leo already handles "~", so we don't need "{{~}}".  
>
>
> Hmm. You are probably right.
>
>> We don't need {{sep}} if the handling code makes the adjustment for "/" 
>> vs "\" automatically.
>
>
> This is the dreaded g.os_path_normslashes. We have to be extremely careful 
> about this issue.  The draft PR #3264 
>  supports only '/' 
> within path expressions, and then only to separate '..' items, so I 
> *think* the draft is good.
>
>   This would be highly desirable anyway because sometimes the best way to 
>> get the right path is to copy it in the OS's file browser and paste it in 
>> directly which will insert native path separators.  Changing them all is a 
>> pain and I find it to be error prone.  And I have sometimes ended up with a 
>> mix of separator types.  Leo should handle this case automatically, 
>> adjusting the separators as needed for the OS.
>
>
> The PR would be broken if you had to change any of your existing outlines 
> that *don't* already use path expressions.
>
>> I agree that ".." steps should be handled correctly but I don't see that 
>> they need to be enclosed in braces.
>>
>
> Another hmm. It seems like a great idea and I'm not sure exactly what Leo 
> already does.
>
> We should try for maximum readability and clarity in the path expressions.
>>
>
> As long as we don't break existing outlines!
>
> In my experience, the biggest need, apart from the separators, is to 
>> adjust the path prefix (the entire path up to but not including the file 
>> name) from one system to another.  
>>
>
> Exactly. That's all the PR allows.
>
>> To me it seems that one capability would be to have conditional 
>> expressions.  For example:
>>
>> @clean {windows: c:\tom\devel\llm; linux: ~/Test/leo/llm}/small_llm_1.py
>>
>
> Let's get the basics working first. 
>
> This kind of hack is why I suggested writing scripts as a workaround.
>
> Thomas, please review the PR.  Thanks.
>
> Edward
>

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

Re: Discuss: what should path expressions contain?

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/3d52741a-08df-4170-a09d-65348b4af66an%40googlegroups.com.

Re: VR3 can now be opened in a tab

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/e8e0b427-a413-426c-862a-dc2f51d11686n%40googlegroups.com.

Re: VR3 can now be opened in a tab

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/b06d3284-58b1-4be9-a493-78e492bf29d8n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Sat, Apr 8, 2023 at 8:01 AM Thomas Passin  wrote:

Leo already handles "~", so we don't need "{{~}}".

Hmm. You are probably right.

> We don't need {{sep}} if the handling code makes the adjustment for "/" vs
> "\" automatically.

This is the dreaded g.os_path_normslashes. We have to be extremely careful
about this issue.  The draft PR #3264
 supports only '/'
within path expressions, and then only to separate '..' items, so I *think*
the draft is good.

  This would be highly desirable anyway because sometimes the best way to
> get the right path is to copy it in the OS's file browser and paste it in
> directly which will insert native path separators.  Changing them all is a
> pain and I find it to be error prone.  And I have sometimes ended up with a
> mix of separator types.  Leo should handle this case automatically,
> adjusting the separators as needed for the OS.

The PR would be broken if you had to change any of your existing outlines
that *don't* already use path expressions.

> I agree that ".." steps should be handled correctly but I don't see that
> they need to be enclosed in braces.
>

Another hmm. It seems like a great idea and I'm not sure exactly what Leo
already does.

We should try for maximum readability and clarity in the path expressions.
>

As long as we don't break existing outlines!

In my experience, the biggest need, apart from the separators, is to adjust
> the path prefix (the entire path up to but not including the file name)
> from one system to another.
>

Exactly. That's all the PR allows.

> To me it seems that one capability would be to have conditional
> expressions.  For example:
>
> @clean {windows: c:\tom\devel\llm; linux: ~/Test/leo/llm}/small_llm_1.py
>

Let's get the basics working first.

This kind of hack is why I suggested writing scripts as a workaround.

Thomas, please review the PR.  Thanks.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2xi91-8ueenRPA6wCgzC2FaZnrsia%3DVDM%2B_n3M27%2BcMA%40mail.gmail.com.

Re: Discuss: what should path expressions contain?

Leo already handles "~", so we don't need "{{~}}".  When I say "handles", I 
mean it adjusts between Windows and Linux.  We don't need {{sep}} if the 
handling code makes the adjustment for "/" vs "\" automatically.  This 
would be highly desirable anyway because sometimes the best way to get the 
right path is to copy it in the OS's file browser and paste it in directly 
which will insert native path separators.  Changing them all is a pain and 
I find it to be error prone.  And I have sometimes ended up with a mix of 
separator types.  Leo should handle this case automatically, adjusting the 
separators as needed for the OS.

I agree that ".." steps should be handled correctly but I don't see that 
they need to be enclosed in braces.  We should try for maximum readability 
and clarity in the path expressions.

In my experience, the biggest need, apart from the separators, is to adjust 
the path prefix (the entire path up to but not including the file name) 
from one system to another.  This could also involve changing from an 
absolute to a relative path.  Here are some use cases:

1. I send a Leo outline along with its external files (perhaps as one of 
the new Leo archive files!).  The outline uses absolute paths for some 
historical reason, but the outline location and the desired location of the 
external files are different for the new user.  The old @file paths may not 
even be valid on the target system - e.g. c:\tom\devel\leo vs ~/Temp/leo - 
even after the separators have been changed.

2. Similar to 1) but I need to move an outline from Windows to Linux so I 
can test my code on both OSs. 

To me it seems that one capability would be to have conditional 
expressions.  For example:

@clean {windows: c:\tom\devel\llm; linux: ~/Test/leo/llm}/small_llm_1.py

Perhaps we could use Python's string format syntax with a custom formatter.
On Saturday, April 8, 2023 at 8:35:43 AM UTC-4 Edward K. Ream wrote:

> On Saturday, April 8, 2023 at 6:43:24 AM UTC-5 Edward K. Ream wrote:
>
> And combinations of the above:
>
> {{../..}}
> {{~/}}
>
>
> And one more, per g.getBaseDirectory:
>
> {{!}}  # g.app.loadDir.
>
> Imo path expressions probably should be allowed only at the start of 
> filenames. I don't see how they could be useful in other positions.
>
> 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/3e193b8c-a1c3-4517-99a2-062db0a0d9e0n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Saturday, April 8, 2023 at 7:35:43 AM UTC-5 Edward K. Ream wrote:

Imo path expressions probably should be allowed only at the start of 
filenames. I don't see how they could be useful in other positions.


In the new scheme path expressions are actually *directory* expressions:

- The *default starting directory* is 
os.path.normpath(os.path.dirname(c.fileName()) 
  An edge case: c.expand_path_expression will fail if the outline doesn't 
yet have a name.

-  '!' and '~' may appear only at the start of the expression.
  They will set the default starting directory accordingly. 

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/29f738c3-da2a-4f9c-ad19-b9be17d34a6en%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Saturday, April 8, 2023 at 6:43:24 AM UTC-5 Edward K. Ream wrote:

And combinations of the above:

{{../..}}
{{~/}}


And one more, per g.getBaseDirectory:

{{!}}  # g.app.loadDir.

Imo path expressions probably should be allowed only at the start of 
filenames. I don't see how they could be useful in other positions.

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/a0ea955d-90fd-46c7-a6d0-ff82eb462849n%40googlegroups.com.

Re: Discuss: what should path expressions contain?

On Sat, Apr 8, 2023 at 6:39 AM Edward K. Ream  wrote:

>
> At minimum, I suppose the following expressions should be valid:
>
> {{~}}  # home
> {{/}}  # os.sep
> {{..}}  # parent directory.
>

And combinations of the above:

{{../..}}
{{~/}}

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/CAMF8tS0Oo%3DA5mn8-eCwnCTVo8-kvDH0kg52EKqWHqC_H6abbew%40mail.gmail.com.

Discuss: what should path expressions contain?

 Recent comments have convinced me that Leo should support *safe* path 
expressions.

I have renamed and rewritten  #3260 
. 

At minimum, I suppose the following expressions should be valid:

{{~}}  # home
{{/}}  # os.sep
{{..}}  # parent directory.

Anything else come to mind :-)

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/7e1415b0-9980-4134-89a3-67cb6c132490n%40googlegroups.com.

Re: Discuss: remove support for Leo's path expressions

On Sat, Apr 8, 2023 at 5:33 AM jkn  wrote:

> I haven't looked at c.expand_path_expression, at least recently - it may
> be too capable for its own good. But I would definitely want a way to
> navigate to a given file under different environments, similar to Tom's
> example.
>
> I could live with the headline having to be changed to accommodate a new
> syntax. As he mentions I would expect '/' to be workable everywhere, for
> example.
>

Thanks for your comment. I'm convinced that *safe *path expressions should
continue to exist.

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/CAMF8tS2RNgXkg41n%3DHLzONa_nYyLzcL3RLRxFCVUDeH_wpmniw%40mail.gmail.com.

Re: Discuss: remove support for Leo's path expressions

On Fri, Apr 7, 2023 at 9:10 PM Thomas Passin  wrote:

> I was thinking the same.  After all, leointeg or leojs could parse
> headlines and do something with the results.   What might  make sense -
> both for security and for both Leo and leojs - would be to write a small
> number of methods that would be the only ones that could be used in path
> expressions.  This would be safer than letting path expressions execute
> arbitrary code.
>

Thanks, Thomas. This is an excellent 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/CAMF8tS3SUjZYoGm8G14bw8%2BbqUYf_R4w7CRoBgFweySe0Cm4Pw%40mail.gmail.com.

Re: Discuss: remove support for Leo's path expressions

On Fri, Apr 7, 2023 at 8:29 PM Félix wrote:

I don't see why vscode would not allow me to evaluate parts of those
> strings as expected by this feature, as I already have support of scripting
> , including offereing g, c, p etc. available in the scope of the running
> scripts.

Many years ago Paul Patternson convinced me (and all of Leo's other devs)
that we must not allow Leo to execute arbitrary scripts when loading a .leo
file. So:

1. leoSettings.leo contains: @bool scripting-at-script-nodes = False
2. Leo allows setting this setting to True *only* in myLeoSettings.leo.

I called this policy the "Lock on the H-Bomb".

Without this policy, opening any .leo file from someone else exposes the
user to malicious code in @script nodes.

Even with this policy, one should be wary of pushing any @button button in
an outline created by someone you don't trust. Ditto for executing any
command created by @command.

In short, .leo files are potential viruses that virus scanners will never
find.

Imo, the security implications of @script, @button and @command are Leo's
biggest unresolvable problem.

Path expressions bypass the lock on the H-Bomb. It's no good requiring a
new lock, as a few minutes thought should convince 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/CAMF8tS1-Ur_CnyO-NE_rB-H2VTw5UJv-tKnm7Gof2R%2BVY3_5jw%40mail.gmail.com.

Re: Discuss: remove support for Leo's path expressions

On Fri, Apr 7, 2023 at 8:28 PM Thomas Passin  wrote:

I'd like to know an easy workaround for *@file
> c:\Tom\devel\leo\some-file.py*  on Windows but, say, *@file
> ~/Leo/outlines/some-file.py.*
>

Create an @button node that adjusts your @file nodes.

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/CAMF8tS3k0MQTBW8QCuskea4VuTftH-UZGFALWsYsnU-%3De_fOXw%40mail.gmail.com.

Re: Discuss: remove support for Leo's path expressions