Edward K. Ream
2018-02-15 14:03:11 UTC
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
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
--
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 post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
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 post to this group, send email to leo-***@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.