Re: A Leo relative in the wild: Trilium Notes

[Matt Wilkie]

Wow. I thought/hoped saying a couple words about Trilium would spark a few
thoughts, but nothing like the way this thread is running. It's amazing.
Thanks all!

-- 
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/CANGB9XTAEmMPkt2bWHs938fLvp0Dj8NnfE%3D-bbJc-WQo9gxHKw%40mail.gmail.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

On Thursday, April 25, 2024 at 1:55:38 PM UTC-4 Thomas Passin wrote:

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.


Once we have such a widget,  VR3 could render right to it, just as it does 
now to a log pane tab. VR3 may not be exactly what we want to end up with 
in the long run, but going this route would very quickly give us a working 
prototype to get experience with.  The approach is to make the rendering 
widget in the new node display widget be VR3's rendering widget.


We already have such a widget and all the machinery we need!  It's the Log 
frame.  We create a frame like the Log frame but with the LeoQt edit widget 
instead of the Log widget.  We put this frame into the location that 
currently holds the edit widget.  We use the same technique to insert the 
VR3 widget into the Log frame but instead we put it into the new 
Edit/Render frame.  This would require no changes to VR3 or the LeoQt edit 
widget.

If all goes well we could even have a prototype working in hours, or days 
at the most.  Most of the work would be in constructing the Edit/Render 
frame (based on the Log frame), and setting it up when a commander is 
constructed.

-- 
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/ac51e552-92c3-41bc-8887-1a6f8c2bcc18n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.


Once we have such a widget,  VR3 could render right to it, just as it does 
now to a log pane tab. VR3 may not be exactly what we want to end up with 
in the long run, but going this route would very quickly give us a working 
prototype to get experience with.  The approach is to make the rendering 
widget in the new node display widget be VR3's rendering widget.

-- 
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/5eb10299-5e92-4e0d-a334-f93a13a6e4e9n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

We are really on the same page here!

On Thursday, April 25, 2024 at 12:39:33 PM UTC-4 Edward K. Ream wrote:

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

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.

Thomas, you may have solved a problem that has bedeviled me for ages! Here 
are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real 
estate.

I completely agree about the real estate.  Almost always, I display VR3 
renderings in a tab in the log pane just for this reason even though the 
view is smaller.  I have a button to toggle the VR3 tab on and off.  When 
off, the delay after each few keystrokes for rendering is not incurred, so 
the button gets used a lot.  BTW, whether in a separate frame or in a tab 
in the log frame, the VR3 display will update as you type.  The same is 
true in freewin if you toggle to the rendered view (you don't type into the 
freewin window, you type into the parent node in the main Leo window).

Edit modes are confusing, but *visual modes* will work! Here are some 
preliminary thoughts:

*Rendering modes*

Both headlines and body text will specify a *default rendering mode* for 
*each *node:

I have been thinking exactly this.  We have to make sure that the defaults 
do the right thing almost all the time so that people who don't care, and 
legacy outlines, work right without needing to change.

- Headlines like @movie and @html (and all the others that VR and VR3 
support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering 
mode, usually *text mode*. However, @language rst would specify *rst mode*.

Exactly; remember that VR3 can handle multiple (software) languages in a 
node (only one rendering language per node, though, i.e., RsT, Md, etc.).  
 It would be nice not to lose that ability.  VR3 can also execute the code 
in a node that has intermixed code and non-code sections.

- A possibility: *@rst-tree* in the headline would specify that the 
rendered contents would consist of the node's body and the bodies of all 
descendant nodes.

Tricky - a long subtree can incur too long a rendering time, or too much 
scrolling, especially when graphics are involved.  That's why VR3 has a 
menu item to render a subtree or only the current node.  I bet we could 
come up with a nearly painless way to do the same, but I have found that I 
want to sometimes see the node and sometimes the tree - so I don't think 
that *@rst-tree* is a good way to go.

*Switching modes*

The *toggle-rendering-mode* command will toggle between the *default *and 
*alternate *rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because 
graphics look very different from text. If confusion does arise, *graphics 
icons* could mark graphics-capable nodes.

Agree. Again, most of the code we need is already working in VR3 and/or 
freewin.  Mainly we need to work out how to provide the overlay frame, and 
how to provide good user controls for switching between text and rendered 
views.

I assume that this capability will be built into the core, since it will 
involve multiple widgets where now there is only an editing widget. We 
should eventually make sure that there is an extension mechanism (via 
plugins) so that people can add new graphic renderings without needing to 
touch core Leo code.

>From an architectural point of view, the current Leo editor widget could 
get replaced by a widget with several child widgets (a tabbed widget is one 
possibility), of which one is the current editor widget, and most keyboard 
and mouse input will go to it no matter whether the text or rendering 
widget is visible.  This plan would require minimal changes to the rest of 
Leo's code.

*Summary*

Rendering body text as either text or graphics seems like a natural idea. 
Why didn't I ever think of this before? And how did we ever live without it?

The *toggle-rendering-mode* command will toggle between graphics and text 
views.
Users are unlikely to become confused about what body panes contain. 

Rendering either text or graphics in the body pane:
- Significantly increases Leo's effective real estate.
- Promises to give Leo the visual capabilities of the most sophisticated 
outliners.

Today is a milestone in Leo's history. And there is further room for 
invention!

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 

Re: A Leo relative in the wild: Trilium Notes

[Edward K. Ream]

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

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.

Thomas, you may have solved a problem that has bedeviled me for ages! Here 
are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real 
estate.

Edit modes are confusing, but *visual modes* will work! Here are some 
preliminary thoughts:

*Rendering modes*

Both headlines and body text will specify a *default rendering mode* for 
*each *node:

- Headlines like @movie and @html (and all the others that VR and VR3 
support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering 
mode, usually *text mode*. However, @language rst would specify *rst mode*.

- A possibility: *@rst-tree* in the headline would specify that the 
rendered contents would consist of the node's body and the bodies of all 
descendant nodes.

*Switching modes*

The *toggle-rendering-mode* command will toggle between the *default *and 
*alternate *rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because 
graphics look very different from text. If confusion does arise, *graphics 
icons* could mark graphics-capable nodes.

*Summary*

Rendering body text as either text or graphics seems like a natural idea. 
Why didn't I ever think of this before? And how did we ever live without it?

The *toggle-rendering-mode* command will toggle between graphics and text 
views.
Users are unlikely to become confused about what body panes contain. 

Rendering either text or graphics in the body pane:
- Significantly increases Leo's effective real estate.
- Promises to give Leo the visual capabilities of the most sophisticated 
outliners.

Today is a milestone in Leo's history. And there is further room for 
invention!

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/74370acc-72c3-4dcc-a1e1-c3299aada5e0n%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: Leo 6.7.8 released to pypi

[HaveF HaveF]

>
> > When I using `pipx inject leo /Users/mac/Desktop/proj/leo-editor` for
> newest code. it throws:
> >error: package directory 'leo/doc/_static' does not exist
>
> > after `mkdir -p leo/doc/_static`, it works as before.
> > Maybe we need an empty .gitignore file in that folder?
>
> Why would an empty .gitignore folder help?
>
> My *speculation *is that perhaps *leo-editor/MANIFEST.in* should contain
> this line:
>
>  include leo/doc/_static
>
> Frankly speaking, I don't know how MANIFEST.in works.
empty .gitignore folder can keep the _static dir in repo, so the error will
be fixed.
Of course, this is indeed not a fundamental solution to error. In fact, I
don't know or track where this error appears (mainly because I think this
matter is not very important). This is just a quick and dirty fix.


> Otoh, I don't understand the differences between pip and pipx.
>
My understanding is: pipx just creates a separate virtual env, and installs
the dependency, after that, it adds the bin dir to the global path. I think
it’s not a problem with pipx. It just creates a separate virtual env for
each installed package.

Btw, my OS is Mac, does anyone else have the same problem as me?

-- 
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/CA%2BUQrQyMUOuDHeUHWtmkVRjHiwjgEQi8QS_SmifJZYXiaEphNg%40mail.gmail.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

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/2903cdcc-8f76-456a-9723-f448afecba32n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Jacob Peck]

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+unsubscr...@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/CAJ1i%2BSYFAmFbSQQ65BqL0C6fAGPLA16gjHp_g%3DzgLAJE5h-xMA%40mail.gmail.com.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

See new issue Allow VR/VR3-style rendering overlaid on standard editing 
nodes .

On Thursday, April 25, 2024 at 8:10:51 AM UTC-4 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3335ebeb-a416-4d23-bf4e-1e741956ee5cn%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Edward K. Ream]

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+unsubscr...@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.

Re: A Leo relative in the wild: Trilium Notes

[Thomas Passin]

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!

On Thursday, April 25, 2024 at 5:12:02 AM UTC-4 Edward K. Ream wrote:

> On Thu, Apr 25, 2024 at 3:49 AM Christoph  wrote:
>
> Of course, dealing with hierarchical data sooner or later requires a 
>> mechanism that allows to put data in more than one branch of the 
>> hierarchy so this seems to be a logical step. However, Leo has taken 
>> this step more than 20 years ago and made it its fundamental design 
>> feature.
>>
>
> And Leo has way better programming features, including c, g, p, 
> generators, @others, @clean, and the Mulder/Ream update algorithm.
>
> I'm not worried about competition, and Félix is several years ahead of 
> would-be imitators.
>
> 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/0589aa0a-96a9-4a47-9531-ac40397f5d56n%40googlegroups.com.

Re: Leo 6.7.8 released to pypi

[Edward K. Ream]

On Thursday, March 28, 2024 at 9:44:52 AM UTC-5 iamap wrote:

> When I using `pipx inject leo /Users/mac/Desktop/proj/leo-editor` for 
newest code. it throws:
>error: package directory 'leo/doc/_static' does not exist

> after `mkdir -p leo/doc/_static`, it works as before.
> Maybe we need an empty .gitignore file in that folder?

Why would an empty .gitignore folder help?

My *speculation *is that perhaps *leo-editor/MANIFEST.in* should contain 
this line:

 include leo/doc/_static

Otoh, I don't understand the differences between pip and pipx.

Do you have any thoughts?

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/a2ccb8d1-d947-46ea-b464-8eb50304b7efn%40googlegroups.com.

Re: Current Devel Branch Fails To Start Using Python 3.9

[Edward K. Ream]

On Wednesday, April 24, 2024 at 11:33:19 AM UTC-5 Edward K. Ream wrote:

> PR #3885  ...moves *from 
typing import TypeAlias* into the range of *if TYPE_CHECKING*:
...
> Even if the import fails, only mypy will be affected. At worst, mypy's 
type checking will be degraded for the five affected files.

I forgot to mention the crucial point: *mypy must pass only on Python 3.12*.

I tolerate (expect!) mypy complaints on earlier versions of Python!

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/0279b844-6e51-47a9-9468-d879e837df39n%40googlegroups.com.

Re: A Leo relative in the wild: Trilium Notes

[Edward K. Ream]

On Thu, Apr 25, 2024 at 3:49 AM Christoph  wrote:

Of course, dealing with hierarchical data sooner or later requires a
> mechanism that allows to put data in more than one branch of the
> hierarchy so this seems to be a logical step. However, Leo has taken
> this step more than 20 years ago and made it its fundamental design
> feature.
>

And Leo has way better programming features, including c, g, p, generators,
@others, @clean, and the Mulder/Ream update algorithm.

I'm not worried about competition, and Félix is several years ahead of
would-be imitators.

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/CAMF8tS3%3DfYWrOkWLuXSSj_ouD6debYuN4%2Bc5TKbKb%3DGL31r73w%40mail.gmail.com.

Re: A Leo relative in the wild: Trilium Notes

[Christoph]

I am under the impression that CherryTree 
(https://www.giuspen.net/cherrytree/) has implemented something similar 
recently:

https://github.com/giuspen/cherrytree/issues/1222
Not sure if it is exactly the same or a variant. Also, Zotero has a 
similar mechanism.
Of course, dealing with hierarchical data sooner or later requires a 
mechanism that allows to put data in more than one branch of the 
hierarchy so this seems to be a logical step. However, Leo has taken 
this step more than 20 years ago and made it its fundamental design feature.


C.

On 4/24/24 21:57, Matt Wilkie wrote:

Hello Leonistas,

I've been exploring a program the last few weeks that seems like it might
be an answer to a long felt wish: to have a Leo-like experience for editing
and managing a rich text and media notes knowledgebase. That program
is *Trilium
Notes* . It's the only application I've
encountered that uses clones in the same sense Leo does and is rooted in a
tree, branch, and node hierarchy graph. It also has executable nodes
(scripting), though unfortunately for my preferences not in python. (Oh
well, one can't ever have it all, right? ;-) I haven't had this much fun
playing with and learning a new software program since encountering Leo
I-can't-remember-how-many years ago.

I'm encountering Trilium at an awkward moment in its life: just as the
primary author is stepping aside. That said, there's a large and
enthusiastic community which has formed *Trilium Next
 *to carry things on. At present they don't
seem to have a gravity center -- imagine twenty people standing at a
doorway emitting "oh no dear madam, after you" -- I believe/hope this will
get sorted soon though.

I don't know if there will come a day when Leo and Trilium share more than
some key architectural and function design decisions, but I figure at least
the communities should be aware of each other. (I'll be composing a similar
"hey did you know about Leo?" message for the Trilium folks too).

Felix, you might be interested to know that Trilium is written in
javascript and the major effort at the moment is converting it to
typescript. They seem to be blazing along on that front. Perhaps there are
some tools or libraries that could be extracted/shared.

cheers,
-matt
  (from away)




--
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/14402b37-3324-4b0a-a026-3d6366b080f2%40gmail.com.