Re: Leo as a Database

[rengel]

What if there were such a tool that fullfills all of your requirements?
Have a look at https://tiddlywiki.com/

On Thursday, March 31, 2022 at 6:45:34 AM UTC+2 tbp1...@gmail.com wrote:

> Thanks for the comments.  I don't disagree with most of them, but of 
> course, "reasons".  I had some user requirements in mind that these choices 
> meet well. The beauty of this point of view - "an outline can be your 
> database" is that there can be many ways of getting there.  These examples 
> are only one way, but they are turning out to be very handy.
>
> As for creation date being encoded in the gnx on one of the examples, 
> perfectly true but not very human readable.  For that example, I thought it 
> would be important for the user to have the least cognitive load possible, 
> and the least chance of making a mistake when interpreting the time.  The 
> id itself is included so that the user can copy it and paste it into 
> another node for navigation and linking purposes (can also be done with a 
> script, which I have bound to CTRL-F7, but having the gnx made manifest may 
> be useful).  Also, with the gnx included in the body, an export to text 
> format (see below) will preserve the gnxes and therefore the links.  
> Keeping them implicit or keeping data in, say, UAs (Unknown or User 
> Attributes) would not export to text easily or automatically.  On last 
> year's discussions of "zettelkasten" systems in Leo, it became clear (at 
> least to some of us) that a capability for export to plain text would be an 
> important consideration.
>
> Some of my user requirements:
> 1. Simplicity - as much like typing simple notes as possible.  Simple 
> hot-keyed scripts can be allowed.
> 2. Easily readable.
> 3. Very extensible.
> 4. Minimal syntax.
> 5. Easy to export to other formats, but especially to a text-only format, 
> in case one wants or needs to leave the Leo environment.
> 6. Maximally simple navigation to other target nodes.
> 7. Make good use of Leo's tree-rearrangement capabilities without needing 
> to change any of the "cards" or navigation links.
> 8. Preferably have a practical way to get a easy-to-read rendered view of 
> a card or subtree.
> 9. Works with clones.
>
> For requirement 5, if you take the top node of your tree of data and make 
> it an @clean node with the only line *@others*, then presto! your whole 
> tree will be saved in text form.  It would be easy enough to write a 
> program to take the gnx values and recreate all the links, then transform 
> to some other format (json, sql load file, whatever).  And that file would 
> be human-readable, searchable (in a text editor) and immediately usable.
>
> You can't have a simpler export than that!  Well, you do lose the 
> organizer nodes and indentation levels.  There's an easy solution to that.
>
> And if you want, say, an export to some XML format - and I'm an old 
> XML/XSLT hand, I've used them for some pretty cool things - it would be 
> fairly easy to write an export script to XML.  In fact, if you wanted to 
> use XQuery as a search language, you might want to export to XML anyway, if 
> only in-memory.
>
> IOW, I am trying for user simplicity, readability, making good use of 
> Leo's features, maximal ability to save your data out to text if needed so 
> your (potentially years of) work can be saved and ported to another system 
> (no lockin to Leo), and simple  navigation possibilities with little if any 
> programming.
>
> So, to pick up on some of your mentions,  or on Lotus Notes (which you 
> didn't mention), they were handicapped by not having Leo (!), and also they 
> weren't trying to meet my set of user requirements.  I didn't mention any 
> builder requirements, but basically they revolve around the potential for 
> writing Leo scripts and commands to improve searching and visualization.  
> Those kinds of scripts are still in early stages, and could probably evolve 
> forever.
> On Wednesday, March 30, 2022 at 11:02:39 PM UTC-4 cve...@gmail.com wrote:
>
>> I like the idea, and I was probably even to some extent thinking of that 
>> sort of usage when considering "leo as a PIM". But you see, this approach 
>> is likely asking for trouble in many ways. Just a few examples : 
>> - aren't you reinventing the wheel to a large extent ? Using your :key: 
>> syntax is Yet Another Way To Code Tags, but is not so different of a json 
>> approach or XML, vCard, ... The buzzwords and bad words here are "standard" 
>> or "registration", "support", "maintenance", etc.
>> - leo's way of using XML cannot benefit of this if I understand 
>> correctly, as it won't code your keys as XML tags  
>> etc. but  and plaintext.
>> - the creation date is redondant with the ID. That's a feature of leo ! 
>> You could have :modified: though and :lastread:, and others
>> - the last part of your example is supposed to contain notes. Why 
>> wouldn't place of birth be a tagged content.
>> - when this becomes a large address book, managing your scri

Re: Ahas re tree traversals

[Edward K. Ream]

On Thu, Mar 31, 2022 at 8:16 PM Edward K. Ream  wrote:

Amazingly, PR #2556 
> already passes all unit tests!
>
...

> At present, the diffs are huge because I created a new copy of most of the
> code. I'll probably redo the work to reduce the diffs.
>

Done in the ekr-simple-ast branch. This branch also includes the latest
work in the ekr-ast-nodes2 branch, which adds support for the new Match*
ast 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/CAMF8tS0StMNX7XoYsBmx48KrRLK6r%2BdJOBR02Esiajgo8GXwhA%40mail.gmail.com.

Re: Leo as a Database

[tbp1...@gmail.com]

I have used t-w several times over the years.  I admire its 
accomplishments.  Somehow I have always ended up moving on.  It may be that 
I found it hard to grasp an overall structure.  It would also be a bear to 
write one's own software for it, and I'm not sure how your data could be 
saved out to generic text and still retain the internal links, if that is 
important.  But yes, if I didn't have Leo I might turn again to t-w.

On Friday, April 1, 2022 at 5:12:56 AM UTC-4 rengel wrote:

> What if there were such a tool that fullfills all of your requirements?
> Have a look at https://tiddlywiki.com/
>
> On Thursday, March 31, 2022 at 6:45:34 AM UTC+2 tbp1...@gmail.com wrote:
>
>> Thanks for the comments.  I don't disagree with most of them, but of 
>> course, "reasons".  I had some user requirements in mind that these choices 
>> meet well. The beauty of this point of view - "an outline can be your 
>> database" is that there can be many ways of getting there.  These examples 
>> are only one way, but they are turning out to be very handy.
>>
>> As for creation date being encoded in the gnx on one of the examples, 
>> perfectly true but not very human readable.  For that example, I thought it 
>> would be important for the user to have the least cognitive load possible, 
>> and the least chance of making a mistake when interpreting the time.  The 
>> id itself is included so that the user can copy it and paste it into 
>> another node for navigation and linking purposes (can also be done with a 
>> script, which I have bound to CTRL-F7, but having the gnx made manifest may 
>> be useful).  Also, with the gnx included in the body, an export to text 
>> format (see below) will preserve the gnxes and therefore the links.  
>> Keeping them implicit or keeping data in, say, UAs (Unknown or User 
>> Attributes) would not export to text easily or automatically.  On last 
>> year's discussions of "zettelkasten" systems in Leo, it became clear (at 
>> least to some of us) that a capability for export to plain text would be an 
>> important consideration.
>>
>> Some of my user requirements:
>> 1. Simplicity - as much like typing simple notes as possible.  Simple 
>> hot-keyed scripts can be allowed.
>> 2. Easily readable.
>> 3. Very extensible.
>> 4. Minimal syntax.
>> 5. Easy to export to other formats, but especially to a text-only format, 
>> in case one wants or needs to leave the Leo environment.
>> 6. Maximally simple navigation to other target nodes.
>> 7. Make good use of Leo's tree-rearrangement capabilities without needing 
>> to change any of the "cards" or navigation links.
>> 8. Preferably have a practical way to get a easy-to-read rendered view of 
>> a card or subtree.
>> 9. Works with clones.
>>
>> For requirement 5, if you take the top node of your tree of data and make 
>> it an @clean node with the only line *@others*, then presto! your whole 
>> tree will be saved in text form.  It would be easy enough to write a 
>> program to take the gnx values and recreate all the links, then transform 
>> to some other format (json, sql load file, whatever).  And that file would 
>> be human-readable, searchable (in a text editor) and immediately usable.
>>
>> You can't have a simpler export than that!  Well, you do lose the 
>> organizer nodes and indentation levels.  There's an easy solution to that.
>>
>> And if you want, say, an export to some XML format - and I'm an old 
>> XML/XSLT hand, I've used them for some pretty cool things - it would be 
>> fairly easy to write an export script to XML.  In fact, if you wanted to 
>> use XQuery as a search language, you might want to export to XML anyway, if 
>> only in-memory.
>>
>> IOW, I am trying for user simplicity, readability, making good use of 
>> Leo's features, maximal ability to save your data out to text if needed so 
>> your (potentially years of) work can be saved and ported to another system 
>> (no lockin to Leo), and simple  navigation possibilities with little if any 
>> programming.
>>
>> So, to pick up on some of your mentions,  or on Lotus Notes (which you 
>> didn't mention), they were handicapped by not having Leo (!), and also they 
>> weren't trying to meet my set of user requirements.  I didn't mention any 
>> builder requirements, but basically they revolve around the potential for 
>> writing Leo scripts and commands to improve searching and visualization.  
>> Those kinds of scripts are still in early stages, and could probably evolve 
>> forever.
>> On Wednesday, March 30, 2022 at 11:02:39 PM UTC-4 cve...@gmail.com wrote:
>>
>>> I like the idea, and I was probably even to some extent thinking of that 
>>> sort of usage when considering "leo as a PIM". But you see, this approach 
>>> is likely asking for trouble in many ways. Just a few examples : 
>>> - aren't you reinventing the wheel to a large extent ? Using your :key: 
>>> syntax is Yet Another Way To Code Tags, but is not so different of a json 
>>> approach or XML, vCard, ...

Re: Simplified Leo Theme Outlines

[Edward K. Ream]

On Wed, Mar 30, 2022 at 12:38 PM tbp1...@gmail.com 
wrote:

> Git hub seems to have added them to the current outstanding PR.  I
> couldn't see a way to create a new one just for these new themes.
>

I have just merged all your PR's into devel, which now contains the entire
6.6.1 code base.

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/CAMF8tS0VJy9pdoeOqtE9u1mxVemD0ihyfahpnW6jwOHrDbg4jg%40mail.gmail.com.

Devel now contains the 6.6.1 code base

[Edward K. Ream]

I have just merged all PR's scheduled for Leo 6.6.1 into devel.

Only two items remain on my list for 6.6.1.

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/481feb52-a12c-4507-a420-c8ae714aeddfn%40googlegroups.com.

Expect Leo 6.6.1 on Friday, April 29

[Edward K. Ream]

I expect to complete all my work for Leo 6.6.1 in a few days, so we shall 
have about a month of testing before 6.6.1 final.

The highlights of 6.6.1:

- Improved support for Python 3.10.
- Simplified leoAst.py.
- Support control-clicking on file names.

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/e3bf471f-fa59-42fb-af4a-dcf6483c8ec4n%40googlegroups.com.

Python 3.10's cool new match statement

[Edward K. Ream]

Python 3.10 

 
supports the new match statement . Don't 
panic, match is a "soft" keyword.

Imo, this is the coolest addition to python since acyncio:

- Pep 634  describes the feature,
- Pep 635  gives the rationale,
- Pep 635  is a tutorial.

Leo issue #2541 provides 
support for the required new ast parse-tree nodes. 

I'm still trying to get my head around the "declarative" style of pattern 
matching. It might be possible to improve Leo's fast-read algorithm using 
this feature.

It *is *possible to (conditionally) use the match statement in Leo's code. 
The trick would be to put the new code in a separate file, say 
leoPython3.10.py. To use the new code, you would try to import functions 
from this file, falling back to legacy code if the import failed.

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/69769d3d-c9ba-4fb8-b20a-db807ac86637n%40googlegroups.com.

Re: Leo as a Database

[rengel]

On Friday, April 1, 2022 at 1:28:15 PM UTC+2 tbp1 wrote:

> I have used t-w several times over the years.  I admire its 
> accomplishments.  Somehow I have always ended up moving on.  It may be that 
> I found it hard to grasp an overall structure.  It would also be a bear to 
> write one's own software for it, *and I'm not sure how your data could be 
> saved out to generic text and still retain the internal links*, if that 
> is important.  But yes, if I didn't have Leo I might turn again to t-w.
>

That's easy. Here is a compelte exported recod (tiddler) as a pure text 
file. Firts, fields/attributes as key-value pairs, then a blank line, then 
any contents of the text field. Internal links in double brackest [[..]]:

""
author: [[Dave Thomas]]
class: Book
created: 20220110171706686
creator: rengel
modified: 20220401151854239
modifier: rengel
publisher: [[The Pragmatic Programmers]]
subtitle: Functional |> Concurrent |> Pragmatic |> Fun
tags: Book
title: Programming Elixir >= 1.6
year: 2018

A book by [[Dave Thomas]] introducing the programming language [[Elixir]].
""


 

-- 
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/f7d6e611-4b18-4978-84a6-8505a73c19aan%40googlegroups.com.

Re: Leo as a Database

[Christophe Vermeulen]

Maybe it doesn't do what I want (I still am quite puzzled with leo, and 
don't understand most of it, just discovered i t recently and played a bit 
messing things up), but in the new 6.6, the "Save As" choices seems 
different : instead of zipped or not, now I see ... JSON/XML/SQLite.. It 
looks to me a huge change, not exactly advertised as would be expected 
IMHO. 

On Friday, April 1, 2022 at 5:27:45 PM UTC+2 rengel wrote:

> On Friday, April 1, 2022 at 1:28:15 PM UTC+2 tbp1 wrote:
>
>> I have used t-w several times over the years.  I admire its 
>> accomplishments.  Somehow I have always ended up moving on.  It may be that 
>> I found it hard to grasp an overall structure.  It would also be a bear to 
>> write one's own software for it, *and I'm not sure how your data could 
>> be saved out to generic text and still retain the internal links*, if 
>> that is important.  But yes, if I didn't have Leo I might turn again to t-w.
>>
>
> That's easy. Here is a compelte exported recod (tiddler) as a pure text 
> file. Firts, fields/attributes as key-value pairs, then a blank line, then 
> any contents of the text field. Internal links in double brackest [[..]]:
>
> ""
> author: [[Dave Thomas]]
> class: Book
> created: 20220110171706686
> creator: rengel
> modified: 20220401151854239
> modifier: rengel
> publisher: [[The Pragmatic Programmers]]
> subtitle: Functional |> Concurrent |> Pragmatic |> Fun
> tags: Book
> title: Programming Elixir >= 1.6
> year: 2018
>
> A book by [[Dave Thomas]] introducing the programming language [[Elixir]].
> ""
>
>
>  
>

-- 
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/171f9f3b-8d0a-43fd-ac3a-f78b6b8f748dn%40googlegroups.com.

Re: Python 3.10's cool new match statement

[Zoom.Quiet]

super,  guido's new tutorial

Edward K. Ream  于2022年4月1日周五 21:39写道：
>
> Python 3.10 supports the new match statement. Don't panic, match is a "soft" 
> keyword.
>
> Imo, this is the coolest addition to python since acyncio:
>
> - Pep 634 describes the feature,
> - Pep 635 gives the rationale,
> - Pep 635 is a tutorial.
>
> Leo issue #2541provides support for the required new ast parse-tree nodes.
>
> I'm still trying to get my head around the "declarative" style of pattern 
> matching. It might be possible to improve Leo's fast-read algorithm using 
> this feature.
>
> It is possible to (conditionally) use the match statement in Leo's code. The 
> trick would be to put the new code in a separate file, say leoPython3.10.py. 
> To use the new code, you would try to import functions from this file, 
> falling back to legacy code if the import failed.
>
> 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/69769d3d-c9ba-4fb8-b20a-db807ac86637n%40googlegroups.com.



-- 

life is pathetic, go Pythonic. 人生苦短, Python当歌 ;-)
课: https://py.101.camp/
怼: https://du.101.camp/
俺: http://zoomquiet.io
许: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦.
KM keep growing environment culture which promoting organization learning ;-)

-- 
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/CAAFijRfMszU%3DkZ6VXt%3DO4JHYTsimTXQ1eS86F9DC9xW_o8pz4w%40mail.gmail.com.