Re: Discuss: remove @root?

[David Szent-Györgyi]

Leo is your project, you provide free access to the fruits of your labor, 
if you're going to remote @root that's your decision, but it may cause me 
to ask questions I need answered if I am to preserve access to work that 
I've done. 

I've written about my use of Leo 4.3: it served as an easily deployed tool 
for building utilities in the form of Windows Script Host files (WSF 
files), and that I came up with a scheme that made it easy for me to use a 
LEO file to hold the source code for the library of routines (in JScript or 
VBScript) used by the WSF files as well as the source code for the 
utilities I was building. Since each WSF file was independent and had to 
include every library routine used therein, the libraries ended up written 
to disk in multiple places in the various WSF files. 

These days, WSF files are frowned up on because script kiddies and other 
malefactors used VBScript and similar technologies, so perhaps I shouldn't 
care about preserving the ones I wrote, but I still use some of them 
in-house, and they need maintenance; I don't want to lose access to my 
Leo-based development environment if I can help it. 

The last thing I would want to do would be cut myself off from Leo's 
vibrant community; I am still a lone developer, working without help to 
write utilities for work when I'm short of time for work as it is. That 
said, if I must give up on using future versions of Leo, what do I do: pick 
a version of Leo that is closest to my needs and create a fork? 

Given that ease of deployment was essential, and that I was happy with the 
functions of Leo 4.3 and the Tkinter-based Leo GUI, my choice of version 
might go back quite a ways. I might have to revive the Tkinter-based GUI; 
I'd have to dig to find out how many releases of Leo ago I'd have to go. 
On Tuesday, February 16, 2021 at 4:26:24 PM UTC-5 Edward K. Ream wrote:

> leoTangle.py supports @root files. Such files are deprecated and no longer 
> documented. This is on purpose.
>
> leoTangle.py contains some of Leo's oldest and least satisfactory code. 
>
> @root is very slightly more flexible than @file, @clean etc. With @root 
> one can define sections (aka chunks) in several places. This ability is one 
> of the features of Knuth's original web and cweb projects. However, I have 
> never, ever, needed this capability. Imo, it is horrendous programming 
> style.
>
> Several (10?) years ago I proposed removing support for @root. Back then 
> at least one person objected. What do you think? Is anyone still using 
> @root?
>
> 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/bccaa651-4bac-4036-a192-785a49fde95dn%40googlegroups.com.

Re: ENB: Aha re snippets, gnx's and literate programming

[Edward K. Ream]

On Thu, Feb 25, 2021 at 8:58 AM tbp1...@gmail.com 
wrote:

> One thing I found helpful in the zettelkasten node references.  When I
> inserted the gnx of a node into a referring node, I also inserted its
> headline.  The search script only used the gnx, but the headline was useful
> for the human looking at it.
>

Right. I'll do something similar.

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/CAMF8tS0-NNDKVArQHdVX-PKzV3M7VWJ%2Bw%3DGmvyJz%2Bw81ENynHg%40mail.gmail.com.

Re: ENB: Aha re snippets, gnx's and literate programming

[tbp1...@gmail.com]

One thing I found helpful in the zettelkasten node references.  When I 
inserted the gnx of a node into a referring node, I also inserted its 
headline.  The search script only used the gnx, but the headline was useful 
for the human looking at it.

An example:

:link: TomP.20200225100827.1 About Leo


On Thursday, February 25, 2021 at 9:51:30 AM UTC-5 Edward K. Ream wrote:

> On Thu, Feb 25, 2021 at 7:14 AM tbp1...@gmail.com  
> wrote:
>
> This sounds similar in concept to the scheme I came up with for the 
>> zettelkasten work.  Any zettel node can contain references to others by 
>> referring to their gnx.  To make it work in a practical way required a 
>> couple of scripts.  One of these scripts inserted the gnx of the node to be 
>> referenced, and also inserted a backlink into that node.
>>
>
> Thanks for this reminder. I'll take another look at your work. Snippets 
> would require similar scripts.
>
>> The big challenge in this kind of system is to keep everything in sync.  
>> Trying to locate gnxs is fine;  trying to match any text that a person may 
>> edit is fragile and prone to getting out of sync.
>>
>
> Not a big problem, imo. Snippet descriptions need only be unique to a 
> particular node. In the usual case, there will be only one snippet in the 
> node, so the description isn't needed. A warning could be given if the 
> description in the reference isn't the same as the description in the 
> defintion. In any case, the gnx can't change, so it will be easy to have 
> Leo link to the offending node.
>
> 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/957a7d67-ade1-4786-a33e-7cb75d6bf0e7n%40googlegroups.com.

Re: ENB: Aha re snippets, gnx's and literate programming

[Edward K. Ream]

On Thu, Feb 25, 2021 at 7:14 AM tbp1...@gmail.com 
wrote:

This sounds similar in concept to the scheme I came up with for the
> zettelkasten work.  Any zettel node can contain references to others by
> referring to their gnx.  To make it work in a practical way required a
> couple of scripts.  One of these scripts inserted the gnx of the node to be
> referenced, and also inserted a backlink into that node.
>

Thanks for this reminder. I'll take another look at your work. Snippets
would require similar scripts.

> The big challenge in this kind of system is to keep everything in sync.
> Trying to locate gnxs is fine;  trying to match any text that a person may
> edit is fragile and prone to getting out of sync.
>

Not a big problem, imo. Snippet descriptions need only be unique to a
particular node. In the usual case, there will be only one snippet in the
node, so the description isn't needed. A warning could be given if the
description in the reference isn't the same as the description in the
defintion. In any case, the gnx can't change, so it will be easy to have
Leo link to the offending node.

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/CAMF8tS2aQCja12e4bUgtZ5%3DJC5mkDLTzdfuoApE-L63_9_W12Q%40mail.gmail.com.

Re: ENB: Aha re snippets, gnx's and literate programming

[tbp1...@gmail.com]

This sounds similar in concept to the scheme I came up with for the 
zettelkasten work.  Any zettel node can contain references to others by 
referring to their gnx.  To make it work in a practical way required a 
couple of scripts.  One of these scripts inserted the gnx of the node to be 
referenced, and also inserted a backlink into that node.

The big challenge in this kind of system is to keep everything in sync.  
Trying to locate gnxs is fine;  trying to match any text that a person may 
edit is fragile and prone to getting out of sync.

On Thursday, February 25, 2021 at 7:58:09 AM UTC-5 Edward K. Ream wrote:

> This Engineering notebook post discusses how to support code/text snippets 
> in Leo. The Aha: gnx's are an underused resource! 
>
> I have been thinking about literate programming (LP), documentation, and 
> related Leo issues. Some links:
>
> - Dynamic Notebooks and Literate Programming 
> 
> - #189 : Better 
> Support for UNL Navigation.
> - #946 : Create a 
> way to isolate documentation in a subnode.
> - #1035 : 
> References to nodes via gnx's or tags.
> - Discussion of retiring @root 
> .
>
> These topics are all related to the wish to make Leo a better mimic of the 
> original goals of LP, which morphs into the desire to allow references to 
> snippets of code, especially in Leo's rst3 command.
>
> Yesterday I realized that gnx's, the unique, unchanging part of each node, 
> provides a way to identify *snippets*, much like org mode's code block:
>
> @snippet 
> 
> @end-snippet
>
> The snippet would be like a section definition. A *snippet reference* would 
> be a text-based way of referring to a particular snippet.
>
> Snippet references will contain the gnx of the node containing the snippet 
> and the *snippet description*. Snippet descriptions need to be unique 
> only within each Leo node.
>
> *Leo will search all open outlines for snippets, *much like Leo searches 
> for @button nodes when we right-click the @button node and choose "Find 
> Script."
>
> *Using snippets in @rst trees*
>
> Inside @rst trees, Leo's rst3 command could support a new kind of @rst 
> node:
>
>   @rst-insert-snippet (description)
>
> These nodes would insert the snippet into the rST output. The body text of 
> @insert-snippet nodes would contain the gnx.
>
> *Using snippets in @file trees*
>
> Similarly, Leo *might *be able to incorporate snippets into external 
> files using a new Leo directive:
>
>  @insert-snippet (description) 
>
> Outlines must define all snippets referenced in @file trees. This 
> constraint will likely ensure that the @file read logic will never fail to 
> find snippets.
>
> *Summary*
>
> Using snippets, users, documents, and scripts can safely use text from all 
> open outlines. Snippets are, in effect, permalinks, uniquely defined by the 
> combination of gnx and description. 
>
> Snippets can become invalid only if the user permanently deletes the node 
> containing the snippets.  Leo will provide tools for finding snippets, just 
> as Leo can find the script corresponding to @button nodes.
>
> Within @rst trees, snippets will provide all LP's features in a more 
> Leonine way.
>
> Snippets *might* also work in @file trees.  If so, snippets would provide 
> most (all?) of the benefits of cross-file clones.
>
> 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/22d35117-b068-4730-b8f0-a106b7e81f8dn%40googlegroups.com.

ENB: Aha re snippets, gnx's and literate programming

[Edward K. Ream]

This Engineering notebook post discusses how to support code/text snippets 
in Leo. The Aha: gnx's are an underused resource! 

I have been thinking about literate programming (LP), documentation, and 
related Leo issues. Some links:

- Dynamic Notebooks and Literate Programming 

- #189 : Better 
Support for UNL Navigation.
- #946 : Create a way 
to isolate documentation in a subnode.
- #1035 : References 
to nodes via gnx's or tags.
- Discussion of retiring @root 
.

These topics are all related to the wish to make Leo a better mimic of the 
original goals of LP, which morphs into the desire to allow references to 
snippets of code, especially in Leo's rst3 command.

Yesterday I realized that gnx's, the unique, unchanging part of each node, 
provides a way to identify *snippets*, much like org mode's code block:

@snippet 

@end-snippet

The snippet would be like a section definition. A *snippet reference* would 
be a text-based way of referring to a particular snippet.

Snippet references will contain the gnx of the node containing the snippet 
and the *snippet description*. Snippet descriptions need to be unique only 
within each Leo node.

*Leo will search all open outlines for snippets, *much like Leo searches 
for @button nodes when we right-click the @button node and choose "Find 
Script."

*Using snippets in @rst trees*

Inside @rst trees, Leo's rst3 command could support a new kind of @rst node:

  @rst-insert-snippet (description)

These nodes would insert the snippet into the rST output. The body text of 
@insert-snippet nodes would contain the gnx.

*Using snippets in @file trees*

Similarly, Leo *might *be able to incorporate snippets into external files 
using a new Leo directive:

 @insert-snippet (description) 

Outlines must define all snippets referenced in @file trees. This 
constraint will likely ensure that the @file read logic will never fail to 
find snippets.

*Summary*

Using snippets, users, documents, and scripts can safely use text from all 
open outlines. Snippets are, in effect, permalinks, uniquely defined by the 
combination of gnx and description. 

Snippets can become invalid only if the user permanently deletes the node 
containing the snippets.  Leo will provide tools for finding snippets, just 
as Leo can find the script corresponding to @button nodes.

Within @rst trees, snippets will provide all LP's features in a more 
Leonine way.

Snippets *might* also work in @file trees.  If so, snippets would provide 
most (all?) of the benefits of cross-file clones.

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/97b44c5e-468b-4403-b90a-21d89e6ea62dn%40googlegroups.com.