2018 will be a momentous year for Leo

[Edward K. Ream]

Don't panic. Momentous does not mean we'll destroy what we have.

I do *not *know where all of this is going to lead. Nothing written here
proves otherwise ;-)


*Web technologies beckon*
When I look at this page <https://webassembly.studio/> I think, I want that
for Leo. Or maybe, "I want Leo technologies to contribute to this".

*What Leo has to offer*

This section extends the ideas in the post An avalanche of new thoughts
<https://groups.google.com/d/msg/leo-editor/Ejf3tif-eJs/cT3ZJINIBAAJ>.
That post discussed which parts of Leo are flexible, and which sclerotic.
There was some code-level bias to those remarks.

Let's ask a slightly less code-centric question. What parts of Leo would be
valuable to the Atom or WebAssembly Studio apps? The list is surprisingly
(refreshingly?) short:

- Leo's data structures (API, DOM, clones, etc.)
- Leo's minibuffer and commands, especially the clone-find commands.
- @clean and the Mulder/Ream update algorithm.
- Leo's outline-based configuration handling.
- (Maybe) Leo's plugin mechanism.

There is a lot that *isn't* on the list:

- All of Leo's Qt code.
- All of Leo's syntax coloring code.

Which is kinda funny, considering how much work Terry and I have put into
this code! We will want to practice of non-attachment in order to consider
replacing all this work with something else.

*Summary*

Cool web technologies/libraries might replace large parts of Leo's code
base. I'll be studying the sources of these cool technologies, looking for
ways to incorporate them into Leo. LeoVue and WebAssembly studio are built
on powerful web components. We must use those components, not reinvent
them.

Leo's core assets are Leo's data structures, Leo's minibuffer-based
commands, and one or two others. Incorporating these assets into *other*
apps, such as Atom or WebAssembly Studio, would guarantee a long life for
the Leonine way.

Given the relatively small amount of code involved, we might seriously
consider rewriting Leo's core assets in javascript or even rust.

Your comments, please, Amigos.

Edward

[Edward K. Ream]

Post by Edward K. Ream
- All of Leo's Qt code.
- All of Leo's syntax coloring code.

The list of non-essentials should include the code that reads/writes .leo
files.

Joe Orr has already translated (part of?) this code into javascript. See
leovue/src/services/leo.js.

Edward

[Edward K. Ream]

On Thursday, February 15, 2018 at 8:03:11 AM UTC-6, Edward K. Ream wrote:

Don't panic. Momentous does not mean we'll destroy what we have.
...

we might seriously consider rewriting Leo's core assets in javascript or
even rust.

I have just written this
<https://users.rust-lang.org/t/python-to-rust-translator/9774/5?u=edreamleo>about
a possible py2rust.py script.

Edward

[Terry Brown]

On Thu, 15 Feb 2018 06:03:11 -0800 (PST)

Post by Edward K. Ream
Leo's core assets are Leo's data structures, Leo's minibuffer-based
commands, and one or two others. Incorporating these assets into

I agree Leo's data structure is one of its greatest assets. Not sure
about the minibuffer commands. I guess vs. any environment that
doesn't support anything similar, they're a major asset.

Post by Edward K. Ream
*other* apps, such as Atom or WebAssembly Studio, would guarantee a
long life for the Leonine way.
Given the relatively small amount of code involved, we might
seriously consider rewriting Leo's core assets in javascript or even
rust.

I think is some ways the issue is not so much web ui vs. Qt UI, but
Python vs. not Python. Python is easily the dominant language in the
domains I work in most, so not Python options aren't super interesting
to me.
https://madnight.github.io/githut/#/pull_requests/2017/4

Re-writing Leo's core is an interesting idea. I think there are some
great opportunities for clarifying the boundaries between the node
storage backend, and the outline representation, and outline
manipulators, and the gui. I'm not saying those boundaries don't
exist, but I think they could be easier to see, leading to the
possibility of interchanging parts more freely.

But my Python bias remains.

Cheers -Terry

[Jacob MacDonald]

Rust has some really nice ergonomics for dealing with data structures. The
possibility of interfacing with Python to implement core data functions in
a faster and safer way is very interesting. Looks like I'll be reading
about writing Python modules in Rust.

Post by Terry Brown
On Thu, 15 Feb 2018 06:03:11 -0800 (PST)

Post by Edward K. Ream
Leo's core assets are Leo's data structures, Leo's minibuffer-based
commands, and one or two others. Incorporating these assets into

I agree Leo's data structure is one of its greatest assets. Not sure
about the minibuffer commands. I guess vs. any environment that
doesn't support anything similar, they're a major asset.

Post by Edward K. Ream
*other* apps, such as Atom or WebAssembly Studio, would guarantee a
long life for the Leonine way.
Given the relatively small amount of code involved, we might
seriously consider rewriting Leo's core assets in javascript or even
rust.

I think is some ways the issue is not so much web ui vs. Qt UI, but
Python vs. not Python. Python is easily the dominant language in the
domains I work in most, so not Python options aren't super interesting
to me.
https://madnight.github.io/githut/#/pull_requests/2017/4
Re-writing Leo's core is an interesting idea. I think there are some
great opportunities for clarifying the boundaries between the node
storage backend, and the outline representation, and outline
manipulators, and the gui. I'm not saying those boundaries don't
exist, but I think they could be easier to see, leading to the
possibility of interchanging parts more freely.
But my Python bias remains.
Cheers -Terry
--
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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Thu, Feb 15, 2018 at 9:14 PM, Jacob MacDonald <***@gmail.com>
wrote:

Rust has some really nice ergonomics for dealing with data structures. The

Post by Jacob MacDonald
possibility of interfacing with Python to implement core data functions in
a faster and safer way is very interesting. Looks like I'll be reading
about writing Python modules in Rust.

​Thanks for this. This
<http://ehiggs.github.io/2015/07/Python-Modules-In-Rust/>was first item
when googling "python modules in rust". There were several others.

For most Rustaceans (heh), it would be much simpler to invoke Leo's bridge
module somehow.

Edward

[Edward K. Ream]

Post by Edward K. Ream
Given the relatively small amount of code involved, we might

Post by Edward K. Ream
seriously consider rewriting Leo's core assets in javascript or even
rust.

I think is some ways the issue is not so much web ui vs. Qt UI, but
Python vs. not Python.

​Thanks for this. It came at the perfect time, when I was about to get
swept away by rust ;-) This post
<https://groups.google.com/d/msg/leo-editor/EaAX7R3_3N0/jKuCjwcuCgAJ> shows
why rewriting Leo's core in rust would be a blunder.

​Edward​
------------------------------------------------------------------------------------------
Edward K. Ream: ***@gmail.com Leo: http://leoeditor.com/
------------------------------------------------------------------------------------------

[Zoom.Quiet]

Post by Terry Brown

Post by Edward K. Ream
Given the relatively small amount of code involved, we might
seriously consider rewriting Leo's core assets in javascript or even
rust.

I think is some ways the issue is not so much web ui vs. Qt UI, but
Python vs. not Python.

Thanks for this. It came at the perfect time, when I was about to get swept
away by rust ;-) This post shows why rewriting Leo's core in rust would be

https://groups.google.com/d/msg/leo-editor/EaAX7R3_3N0/jKuCjwcuCgAJ

a blunder.

#WoW thanx EKR for astute decide,
Leo's core base Python is very necessary,
and support others language for plugins develop is not hard for Python core.

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
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

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

[Edward K. Ream]

It has *already *been a momentous year:

- We have a great new git workflow. See branches.md for details. This
picture
<Loading Image...>
summarizes the idea.

- #770 <https://github.com/leo-editor/leo-editor/issues/770> summarizes
the plans for making Leo's existing features more visible.

- Joe Orr continues to improve LeoVue.

- Vitalije has an ambitious plan (#768)
<https://github.com/leo-editor/leo-editor/issues/768> to greatly speed
Leo's tree code.

And on and on. All in the last two weeks.

Edward