ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

This Engineering Notebook post contains second thoughts about Trilium 
Notes. 

*tl;dr:* Leo might add only *incremental *improvements inspired by Trilium 
Notes. All fundamental aspects of Leo will remain as they are.

*Leo's body pane*

Yesterday, I proposed that Leo's body might contain either text (p.b) or 
graphics (the VR pane). I now think that's a dubious idea. Instead, the VR 
pane could (optionally) be a separate window.

Swapping the contents of the body pane creates more problems than it solves:

- The UI (and its rationale) becomes significantly more complex. There are 
hidden rules at work.

- The UI prevents users from seeing both p.b and the VR pane 
simultaneously. Trilium sometimes works around this problem by showing the 
source and results in the same pane.

- Leo's body pane is anchored and can't expand or move.

Allowing the VR pane to be a separate window solves all these problems.

*Trilium's strengths*

Trilium emphasizes graphics throughout.

I particularly like the demo of Mermaid Diagrams . 
Mermaid is a Javascript project. Several vs-code plugins support such 
diagrams, so LeoInteg and LeoJS already have access to Mermaid Diagrams! 
The Python world has python-mermaid 
, so Leo's VR plugins could 
support Mermaid too.

*Trilium's weaknesses*

Trilium undervalues the power of text:

- There is no minibuffer and no way to execute commands by name. There are 
no menus! Instead, small icons must suffice. 

- Organizer nodes contain "preview cards" (my term) that show rendering 
descendant nodes. There is no obvious way to create text summaries of a 
sub-tree.

- Trilium can not create external files. Unless I am mistaken, one can only 
export nodes.

*Ideas worth emulating*

Trilium nodes often show the "attached" css and Javascript. These views 
seem like the inverse of Leo's @button scripts. Some possibilities for Leo:

-- A new *p.css* property. This property would contain css that modified 
the view of p.b or the VR pane. Setting this property might require a new 
UI element.

-- A new *p.ui_script* property. This property might contain the rendering 
script in effect for the node. For security reasons, this property *must 
not* be settable.

As discussed in a previous post, the VR plugins could render *@rst-tree* nodes 
using all the node's descendants. And Leo's rst3 command might support 
@graphics and other VR-related nodes.

*A plugin-base VR architecture*

Leo's existing VR and VR3 plugins are monolithic. Both plugins would 
benefit from a more modular organization.

*Summary*

*Changing the rendering of Leo's body pane is a dubious idea.* Instead:

- As an option, the VR pane could become a floating window.

- The VR pane could use a modular architecture based on plugins. I look 
forward to discussing this topic with Thomas.

- Leo's rst3 command might support VR-related nodes.

I welcome all comments.

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/36442543-525b-4ca1-8d86-9097c884f161n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium 
Notes. 

*tl;dr:* Leo might add only *incremental *improvements inspired by Trilium 
Notes. All fundamental aspects of Leo will remain as they are.

*Summary*

*Changing the rendering of Leo's body pane is a dubious idea.* Instead:

- As an option, the VR pane could become a floating window.

This is already possible, at least with VR3.  With VR3 enabled, right click 
on the boundary between two frames to get the splitter menu.  Select 
*Window* then *VR3*.  VR3 opens in a new floating window.  Presumably if 
only VR were enabled you could do the same (untested). The whole procedure 
is a little awkward but presumably could be made to work from a command or 
button.

[Aside - this capability is a tribute to the people who worked up the 
splitter mechanism (was that Terry Brown?).  Plugins like VR3 were not 
written with any code to become free-floating windows, but the basic plugin 
mechanism automatically makes them available to the splitter machinery, 
which can do the job.]

I have found that using a view like VR3 in a separate window is not as 
useful as I would like because window overlaps obscure too much.  It would 
work fairly well with a very wide monitor.  Freewin is also a freefloating 
window, and it can switch between text and rendered views, but the expected 
usage lends itself better to using several narrower windows next to the 
main Leo window.  Freewin was intended mostly for comparing two nodes while 
being live with its underlying host node so that the host can be edited 
while looking at the comparison node.

- The VR pane could use a modular architecture based on plugins. I look 
forward to discussing this topic with Thomas.

VR/VR3 basically work in a way that could be more modularized, I would 
think.  Basically, the plugin must:
1. Figure out what kind of node it is looking at, usually by page 
directives like *@language;*
2. Send the contents of the node or subtree to some appropriate code that 
transforms it into HTML;
3. Send the HTML to a rendering engine;  This is normally the Qt WebEngine 
widget (for VR3) but could be something else.  As an alternative, for a 
node with computer code the code can be extracted and sent to a code engine 
for execution.  VR3 can collect and display or execute all the code chunks 
even if they are separated by non-code parts (so VR3 can do literate 
programming basically for free).

- Leo's rst3 command might support VR-related nodes.

I'm not sure just what this means - "VR-related nodes".  VR3 can already 
render an rst tree because it can (optionally) render any subtree.  So you 
can get an approximation of what your document will look like, including 
any graphics. I use this capability when I author a Sphinx document.  It's 
very handy. But it is limited because some internal links and other 
features have to be created by Sphinx after the rst3 command has been 
issued so you can't get a fully complete rendering just from the Leo nodes.

I welcome all comments.

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/c81dac45-fec8-4f9b-9a31-6debcea505a4n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

This Engineering Notebook post contains second thoughts about Trilium Notes.

*Trilium's weaknesses*

Trilium undervalues the power of text:

I think that Edward does not appreciate how often users want to use Leo as 
an *Notebook* as opposed to a *writing* tool.  For a notebook, one wants to 
include all kinds of material, text and graphics, and then *look at and 
read* it many times.  For writing, developing code, and so on one mostly 
wants to *edit and read text*. Trillium by default, it seems to me, shows 
you a rendered view of its nodes and makes it harder to edit and work with 
the content.  Leo makes it easy to edit and work with text, but harder to 
insert and look at rendered graphics, etc.

An example is those Mermaid diagrams.  Leo can't currently use Mermaid, but 
it can create and render Plantum diagrams, which are somewhat similar, 
using VR3 with Asciidoc.  It's necessary to install a stand-alone Asciidoc 
engine with the right plugins, but it's very feasible.  Once created, I at 
least would like to see a series of diagrams rendered.  The text view would 
be useless, and it's unlikely I would be changing the diagrams once 
perfected.  Seeing the textual source would be a distraction.

Think about how Jupyter notebooks are usually used.  It's great to be able 
to develop your code in one, complete with graphics and notes.  But once 
developed, they are generally shared as a set of HTML  files, and only 
looked at not edited.  VR3 can display those files using an @jupyter node 
type.  Any text display would only show the raw html, which is essentially 
useless and distracting to look at.

-- 
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/6af83645-d756-4029-b1c4-5e4fa93f4db9n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> As an option, the VR pane could become a floating window.

> This is already possible, at least with VR3.  With VR3 enabled, right
click on the boundary between two frames to get the splitter menu.  Select
*Window* then *VR3*.  VR3 opens in a new floating window.

Surely this can be done w/o Terry's Easter Egg.

> I have found that using a view like VR3 in a separate window is not as
useful as I would like because window overlaps obscure too much.  It would
work fairly well with a very wide monitor.

I'm interested in an easy prototype. It doesn't have to be perfect.

VR/VR3 basically work in a way that could be more modularized, I would
> think.  Basically, the plugin must:
> 1. Figure out what kind of node it is looking at, usually by page
> directives like *@language;*
> 2. Send the contents of the node or subtree to some appropriate code that
> transforms it into HTML;
> 3. Send the HTML to a rendering engine;
>

Yes, that's similar to what I was thinking.

I envisage different nodes per each kind of node that VR or VR3 can handle.

That's what I meant by VR-related nodes.

*Summary*

We agree on enough to continue our conversation :-)

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/CAMF8tS2L-jso6AQOmiegjUvxcTY-eM%3D4W5f%2By8%2BoOARgO6VBng%40mail.gmail.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 1:13:38 PM UTC-4 Edward K. Ream wrote:

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> As an option, the VR pane could become a floating window. 

> This is already possible, at least with VR3.  With VR3 enabled, right 
click on the boundary between two frames to get the splitter menu.  Select 
*Window* then *VR3*.  VR3 opens in a new floating window.  

Surely this can be done w/o Terry's Easter Egg.


I wouldn't call it an Easter Egg, exactly, because it's not really hidden.  
But it's awkward to use.  It seems to me that whatever command is called by 
the final splitter menu selection - if we can figure out what it is - 
should be callable by some other means.  I'd rather do that than mess with 
the VR3 code at this stage.  BTW, you can open a standard body editing pane 
as a separate window in the same way.

-- 
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/64ab1c7c-3594-436a-847d-e61a1343bbe5n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  wrote:

>> Trilium undervalues the power of text:

> I think that Edward does not appreciate how often users want to use Leo
as a Notebook...

I agree. Leonistas *should *be able to use lots of graphics :-) That's why
improving the VR plugins and (maybe) the rst3 plugin seems like a good idea.

> Trillium...shows you a rendered view of its nodes and makes it harder to
edit and work with the content.

> Leo makes it easy to edit and work with text, but harder to insert and
look at rendered graphics, etc.

That's a reasonable summary. A floating VR pane would be a step forward.

> VR3 can display [jupyter] files using an @jupyter node type. Any text
display would only show the raw html...

Yes, sometimes the rendered view is preferable. But that's no reason to
complicate Leo's interface.

*Summary*

The Easter Egg is the only way to expand the VR pane. An optional floating
VR window would solve that problem.

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

Re: ENB: Seconds thoughts about Trilium Notes

[Jacob Peck]

Why would a floating window solve any problems here?  How are you
envisioning that a floating VR3 window, *which can already be done* *today
without any additional coding*, would help the situation?

As a counterpoint, I only have a single display available to me.  I
generally do my work (in Leo) on a single desktop monitor, or a tiny laptop
screen.  In *both cases* I would much prefer a switchable pane, rather than
a floating window.  The current solution of VR eating up a third of the
screen by default, or of faffing about with a floating window (even more
irksome on a laptop with a touchpad), is such a poor UX that I avoid it.
Enough so that I've effectively stopped using Leo for anything that needs
to be rendered.

Adding a first-class 'floating window' feature to VR/3 wouldn't fix any
issues.  It would strictly exacerbate the issue.  But a context-aware
switchable tab, which is eminently doable, would solve *every single one*
of my personal problems.  And I know it's a workable solution *because I've
done it*.

Leo is, to me, an editor, an IDE, and a platform.  But it is increasingly
*not* an authoring tool for me, because of the current implementation of
VR.  And that's frustrating, because authoring any sort of complex
documentation *should be* where Leo shines, given the first-class outlining
and clones.

Just my $0.02.  I wish we wouldn't just discard things out of hand because
of perceived 'dubiousness'.  Experimentation is fruitful, and painless,
given git branching.

Jake

On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:

> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin 
> wrote:
>
> >> Trilium undervalues the power of text:
>
> > I think that Edward does not appreciate how often users want to use Leo
> as a Notebook...
>
> I agree. Leonistas *should *be able to use lots of graphics :-) That's
> why improving the VR plugins and (maybe) the rst3 plugin seems like a good
> idea.
>
> > Trillium...shows you a rendered view of its nodes and makes it harder to
> edit and work with the content.
>
> > Leo makes it easy to edit and work with text, but harder to insert and
> look at rendered graphics, etc.
>
> That's a reasonable summary. A floating VR pane would be a step forward.
>
> > VR3 can display [jupyter] files using an @jupyter node type. Any text
> display would only show the raw html...
>
> Yes, sometimes the rendered view is preferable. But that's no reason to
> complicate Leo's interface.
>
> *Summary*
>
> The Easter Egg is the only way to expand the VR pane. An optional floating
> VR window would solve that problem.
>
> 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/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%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%2BSYr2DEPMRRaA9Xr%2BXdUx-a1r%2B%2Bj7Z0zxJ8LxTwTvG998Q%40mail.gmail.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

I'm with you here.  Between VR3 and Freewin, I've tried floating windows, 
new frames, and rendering into a tab in the log frame.  Freewin has a 
switchable display (edit <-> render) and I find that convenient and easy to 
work with, even without a way to set the default to *render*. Having the 
body pane display style be switchable would work very well for me as a UI, 
should not be hard to implement, and would not preclude any of those other 
display modes.

On Friday, April 26, 2024 at 1:52:49 PM UTC-4 gates...@gmail.com wrote:

> Why would a floating window solve any problems here?  How are you 
> envisioning that a floating VR3 window, *which can already be done* *today 
> without any additional coding*, would help the situation?
>
> As a counterpoint, I only have a single display available to me.  I 
> generally do my work (in Leo) on a single desktop monitor, or a tiny laptop 
> screen.  In *both cases* I would much prefer a switchable pane, rather 
> than a floating window.  The current solution of VR eating up a third of 
> the screen by default, or of faffing about with a floating window (even 
> more irksome on a laptop with a touchpad), is such a poor UX that I avoid 
> it. Enough so that I've effectively stopped using Leo for anything that 
> needs to be rendered.
>
> Adding a first-class 'floating window' feature to VR/3 wouldn't fix any 
> issues.  It would strictly exacerbate the issue.  But a context-aware 
> switchable tab, which is eminently doable, would solve *every single one* 
> of my personal problems.  And I know it's a workable solution *because 
> I've done it*.
>
> Leo is, to me, an editor, an IDE, and a platform.  But it is increasingly 
> *not* an authoring tool for me, because of the current implementation of 
> VR.  And that's frustrating, because authoring any sort of complex 
> documentation *should be* where Leo shines, given the first-class 
> outlining and clones.
>
> Just my $0.02.  I wish we wouldn't just discard things out of hand because 
> of perceived 'dubiousness'.  Experimentation is fruitful, and painless, 
> given git branching.
>
> Jake
>
> On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:
>
>> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  wrote:
>>
>> >> Trilium undervalues the power of text:
>>
>> > I think that Edward does not appreciate how often users want to use Leo 
>> as a Notebook...
>>
>> I agree. Leonistas *should *be able to use lots of graphics :-) That's 
>> why improving the VR plugins and (maybe) the rst3 plugin seems like a good 
>> idea.
>>
>> > Trillium...shows you a rendered view of its nodes and makes it harder 
>> to edit and work with the content.
>>
>> > Leo makes it easy to edit and work with text, but harder to insert and 
>> look at rendered graphics, etc.
>>
>> That's a reasonable summary. A floating VR pane would be a step forward.
>>
>> > VR3 can display [jupyter] files using an @jupyter node type. Any text 
>> display would only show the raw html...
>>
>> Yes, sometimes the rendered view is preferable. But that's no reason to 
>> complicate Leo's interface.
>>
>> *Summary*
>>
>> The Easter Egg is the only way to expand the VR pane. An optional 
>> floating VR window would solve that problem.
>>
>> 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/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%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/47847ae3-a0eb-45ef-993b-957beece1c2cn%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Thomas Passin]

On Friday, April 26, 2024 at 1:31:41 PM UTC-4 Edward K. Ream wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating 
VR window would solve that problem.


Here you go:

ns = c.free_layout.get_top_splitter()
ns.open_window('_leo_viewrendered3')
 

-- 
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/a9734be6-dc2c-44ee-adea-9310dead5cd3n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

On Fri, Apr 26, 2024 at 2:38 PM Thomas Passin wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating
> VR window would solve that problem.
>
>
> Here you go:
>
> ns = c.free_layout.get_top_splitter()
> ns.open_window('_leo_viewrendered3')
>

Wow. Thanks for this.

And thanks for all the comments. They have all been helpful.

Let me summarize the discussion so far:

- I'm convinced. Replacing the body pane is a *preference* *worth
considering*.

- That preference should also allow opening the VR pane as a separate
window.

- A modular architecture for the VR pane (including VR3) is a separate
issue.

I'm interested in both issues, but neither is an urgent priority.

Let's continue this fruitful discussion!

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

Re: ENB: Seconds thoughts about Trilium Notes

[Matt Wilkie]

*>Trilium's weaknesses:>There is no minibuffer and no way to execute
commands by name. *

 True, but not fundamentally blocked. In the Awesome Trilium
 list is a js plugin for adding
a command-palette. I imagine it's modelled after vs-code's Ctrl-Shift-P
type-name-looking-for.

*>There are no menus! Instead, small icons must suffice*

 yeah, I'm not so fond of there being no menu at all. Mitigating that a bit
is the F1 popup quick reference for the most used keyboard shortcuts. It is
excellent.

*Trilium can not create external files. Unless I am mistaken, one can only
export nodes.*

Yes, a big difference and a lack from my perspective.

*Fundamental differences* (observed so far)*:*

Leo is plain text first, and achieves rich text and media by rendering.
Trilium is rich text and media first, with the primary entry mechanism
through the 3rd party CKEditor which saves as html. This is the
foundational split behind the whole VR and multiple panes *(pains? heheh)*
vs single pane thinking and attendant mitigation machinery. Trilium doesn't
have to think about rendering hardly at all, since it's the embedded
browser that does that.

Leo uses the file system for storage and Trilium uses sqlite. This gives
Leo its external files extended abilities very nearly for free. For Trilium
to adopt such features would be an exercise of some effort. Otoh, being
able to run sql queries across all nodes can't be anything but powerful.
(In Trilium access the SQL Console via Alt-0 or the flower logo at top
left; yeah, speaks to lack of menu).

It's this db backend which enables syncing one's entire KB across all
devices in a pretty much set-and-forget manner. It's almost as good as
Fossil SCM in this regard. This is very, very attractive.

Another Trilium limit: there's only a single knowledge database. ALL your
Trilium work is one place. There is discussion on a future with multiple db
but nothing substantive that I've seen. I'm new to the space and might be
missing the action though.)

-matt



On Fri, Apr 26, 2024 at 12:50 PM Edward K. Ream  wrote:

> On Fri, Apr 26, 2024 at 2:38 PM Thomas Passin wrote:
>
> The Easter Egg is the only way to expand the VR pane. An optional floating
>> VR window would solve that problem.
>>
>>
>> Here you go:
>>
>> ns = c.free_layout.get_top_splitter()
>> ns.open_window('_leo_viewrendered3')
>>
>
> Wow. Thanks for this.
>
> And thanks for all the comments. They have all been helpful.
>
> Let me summarize the discussion so far:
>
> - I'm convinced. Replacing the body pane is a *preference* *worth
> considering*.
>
> - That preference should also allow opening the VR pane as a separate
> window.
>
> - A modular architecture for the VR pane (including VR3) is a separate
> issue.
>
> I'm interested in both issues, but neither is an urgent priority.
>
> Let's continue this fruitful discussion!
>
> 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/CAMF8tS2UMXdzzfz2jvCRzQj8x6NRRF4yoK_OjEedFfkJ5dG0UA%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/CANGB9XRmAw-oUBGXBUHqw5EMQGbKw4GvbGdHu8mNx5bba0OfRg%40mail.gmail.com.