Re: 2018 will be a momentous year for Leo

[Edward K. Ream]

It has *already *been a momentous year:

- We have a great new git workflow.  See branches.md for details. This 
picture 

 
summarizes the idea.

-  #770  summarizes 
the plans for making Leo's existing features more visible.

- Joe Orr continues to improve LeoVue.

- Vitalije has an ambitious plan (#768) 
 to greatly speed 
Leo's tree code.

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

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

Re: 2018 will be a momentous year for Leo

[Edward K. Ream]

On Thu, Feb 15, 2018 at 9:14 PM, Jacob MacDonald 
wrote:

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.


​Thanks for this.  This
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

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

Re: 2018 will be a momentous year for Leo

[Zoom.Quiet]

On Fri, Feb 16, 2018 at 5:48 PM, Edward K. Ream  wrote:
> On Thu, Feb 15, 2018 at 1:21 PM, Terry Brown  wrote:
>
>> > 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
> --
> Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.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 post to this group, send email to leo-editor@googlegroups.com.
> 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!

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

Re: 2018 will be a momentous year for Leo

[Edward K. Ream]

On Thu, Feb 15, 2018 at 1:21 PM, Terry Brown  wrote:

> 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 a blunder.

​Edward​
--
Edward K. Ream: edream...@gmail.com Leo: http://leoeditor.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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: 2018 will be a momentous year for Leo

[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.

On Thu, Feb 15, 2018, 13:21 Terry Brown  wrote:

> On Thu, 15 Feb 2018 06:03:11 -0800 (PST)
> "Edward K. Ream"  wrote:
>
> > 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.
>
> > *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
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: 2018 will be a momentous year for Leo

[Terry Brown]

On Thu, 15 Feb 2018 06:03:11 -0800 (PST)
"Edward K. Ream"  wrote:

> 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.

> *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 email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: 2018 will be a momentous year for Leo

[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 
about
 
a possible py2rust.py script.

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

Re: 2018 will be a momentous year for Leo

[Edward K. Ream]

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

There is a lot that *isn't* on the list [of Leo's core assets]:
>
> - 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

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

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  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 
.  
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.