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 <tbp1...@gmail.com> 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
> <https://github.com/leo-editor/leo-editor/pull/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.
