Re: ENB: Serious doubts about embedding Leo

[Edward K. Ream]

On Friday, February 23, 2018 at 3:37:32 AM UTC-6, Edward K. Ream wrote:

> leoBridge.py is a small module, but it has generated continuing and 
difficult issues.

Vitalije has just fixed multiple issues, including two issues related to 
the leo bridge:

#716: LeoBridge not explicitly closing the Leo-Editor file leaves the 
Leo-Editor file open 

#642: The external change to Leo-Editor file(s) query is very puzzling 


Neither of these had any previous milestone attached because I had no idea 
how to fix them.  Many thanks, Vitalije, for this great work.  These fixes 
are in master and will appear in Leo 5.7 final.

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: ENB: Serious doubts about embedding Leo

[Edward K. Ream]

On Friday, February 23, 2018 at 4:05:36 AM UTC-6, Zoom.Quiet wrote:

> WoW soo quickly conform these points ;- just 2 week, EKR rebuild IDE 
world idea, Sayeahoo!

Hehe.  Two weeks of prototyping, building and playing with other editors is 
a small price to pay for a wider view of the world.

*Update*: I went back to bed after writing this post in the middle of the 
night.  When I awoke my first feelings were of relief that I would no 
longer be considering (or doing!) large and foolish projects.  So my 
subconscious is giving me a preliminary thumbs up.

>> Embedding Leo in another IDE would create ripple effects that touch *all* 
of Leo's code.  These ripple effects would depend on arcane details of the 
particular IDE in which Leo is embedded.

ripple effects  <~~~ very right define,
> appended one reason:
> embedding others IDE ecosystem is hold one huge upstream into Leo's 
> ecosystem;
> but the upstream ecosystem is out-control by EKR,
> means for Leo's new feature can compatibility upstream ecosystem,
> will ripple huge unnecessary work.
>

Excellent point. I had not consciously seen it as clearly as you have.

> Leo will remain a pure python app, scriptable in python.
> I shall incorporate some of eric6's features into Leo's code base.
> Leo must have a plugin that supports Joe Orr's great work.
   This plugin will be worth *any* amount of work.
> I am happy with these conclusions.

only one suggest:
> this paper must insert into LeoDoc, maybe as FAQ?
>

Will do. Thanks for this suggestion.

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: ENB: Serious doubts about embedding Leo

[Zoom.Quiet]

On Fri, Feb 23, 2018 at 6:05 PM, Zoom.Quiet  wrote:

> On Fri, Feb 23, 2018 at 5:37 PM, Edward K. Ream 
> wrote:
>
>> The process of *considering* embedding Leo in another IDE has been one
>> of the most useful things I have ever done.  I feel as if I have awoken
>> from a deep slumber.  Atom, VSCode, eric6 and Pycharm/Intellij are all
>> superb tools.  Building and using them, even briefly, has been eye opening.
>>
>> But embedding Leo in another IDE would be a big mistake. This posts
>> explains why.
>>
>> This is a long post. To state my conclusions first:
>>
>> - Embedding Leo in any IDE would be a huge and risky project.
>> - Such a project would distract us Leo devs, and burden us with endless
>> support.
>> - Embedding Leo would be less useful than it might seem.
>> - Leo has its own strengths. Many don't translate easily to other IDE's.
>>
>>
> WoW soo quickly conform these points ;-)
>
confirm

> just 2 week, ERK rebuild IDE world idea, Sayeahoo!
>
> EKR <~ so sorry, i always type error abbreviation

>
>
>> See the summary for other conclusions.
>>
>> *A huge and risky project*
>>
>> Embedding Leo in any IDE would be much harder than it might appear at
>> first.  At *minimum*, such a task would require an *entirely new* gui
>> plugin for Leo. Such plugins have been the biggest projects in Leo's
>> history.
>>
>> This became obvious to me yesterday while reading/reformatting the eric6
>> plugin guide. Eric6 is a pure python app, but the eric6 ecosystem is almost
>> completely different from Leo's. There is likely *no* clever way to use
>> Leo's existing Qt code.  Everything would likely have to be rewritten.
>>
>> Embedding Leo in another IDE would create ripple effects that touch *all*
>> of Leo's code.  These ripple effects would depend on arcane details of the
>> particular IDE in which Leo is embedded.
>>
>>
> ripple effects  <~~~ very right define,
> appended one reason:
> embedding others IDE ecosystem is hold one huge upstream into Leo's
> ecosystem;
> but the upstream ecosystem is out-control by ERK,
> means for Leo's new feature can compatibility upstream ecosystem,
> will ripple huge unnecessary work.
>
>
>> It's impossible to know beforehand what the final design and code would
>> look like. This makes such projects extremely risky. Quick prototypes won't
>> significantly reduce the risk. Rather, they are likely to be wasted
>> investments.
>>
>> *Endless distractions*
>>
>> Successful projects have limited focus, no matter how many devs are
>> involved. Embedding Leo in another IDE would be a major, most unwise,
>> commitment of time and energy for all Leo devs.
>>
>> Support would be endless. For example, leoBridge.py is a small module,
>> but it has generated continuing and difficult issues. One of those issues
>> required tricky futzing with gnx's when loading .leo files. Just recently I
>> had to tweak that code again.
>>
>> Do we want to answer endless questions about how to build Pycharm, or
>> whatever?  Do we want to tell people how to *use *Leo in other IDE's?
>> Finally, do we want to complicate Leo's distros with javascript related
>> matters?
>>
>> *Expensive advertising*
>>
>> My dream has been to promote Leo by offering its features in other
>> environments. I'm ready to say now that this has always been a bad idea :-)
>>
>> I've learned in the past week or so that it's (usually) pretty easy to
>> download and run other IDE's. People can and do use more than one IDE.
>> People know where to find Leo.  Creating a Leo plugin in any other IDE
>> would be an expensive and ineffective form of advertising.
>>
>> *Leo's strengths*
>>
>> In one of my first posts I said that just about everything Leo *shares*
>> with Atom is inferior to Atom.  But this statement was *just plain wrong*
>> . Here are some common areas in which Leo excels:
>>
>> 1. Scripting. Most IDE's aren't scriptable at all, so technically my
>> remarks don't apply ;-)
>>
>> 2. Plugins. Leo's plugin architecture is much simpler than eric6, and
>> that's the easy case.
>>
>> 3. Searching. No other platform has Leo's clone find commands. etc.
>>
>> 4. Commands. Outline-oriented diffs exist nowhere else. etc.
>>
>> 5. Settings and configuration.  eric6 has a nifty gui representation of
>> its settings, but Leo's settings are much more flexible:
>>
>> - Settings can apply to individual .leo files.
>> - Settings nodes naturally contain arbitrarily verbose comments.
>> - Users can organize settings trees as they like.
>> - Plugins can add settings just by calling c.config.getBool, etc.,
>> *without* adding to Leo's gui code.
>>
>> 6. Window system. Terry has made Leo's window system scriptable (in
>> python!) and extensible.
>>
>> *Summary*
>>
>> Leo will remain a pure python app, scriptable in python.
>>
>> There is much to learn from eric6. I shall incorporate some of eric6's
>> features into Leo's code base.
>>
>> Leo must have a plugin that supports Joe Orr's great 

Re: ENB: Serious doubts about embedding Leo

[Zoom.Quiet]

On Fri, Feb 23, 2018 at 5:37 PM, Edward K. Ream  wrote:

> The process of *considering* embedding Leo in another IDE has been one of
> the most useful things I have ever done.  I feel as if I have awoken from a
> deep slumber.  Atom, VSCode, eric6 and Pycharm/Intellij are all superb
> tools.  Building and using them, even briefly, has been eye opening.
>
> But embedding Leo in another IDE would be a big mistake. This posts
> explains why.
>
> This is a long post. To state my conclusions first:
>
> - Embedding Leo in any IDE would be a huge and risky project.
> - Such a project would distract us Leo devs, and burden us with endless
> support.
> - Embedding Leo would be less useful than it might seem.
> - Leo has its own strengths. Many don't translate easily to other IDE's.
>
>
WoW soo quickly conform these points ;-)
just 2 week, ERK rebuild IDE world idea, Sayeahoo!



> See the summary for other conclusions.
>
> *A huge and risky project*
>
> Embedding Leo in any IDE would be much harder than it might appear at
> first.  At *minimum*, such a task would require an *entirely new* gui
> plugin for Leo. Such plugins have been the biggest projects in Leo's
> history.
>
> This became obvious to me yesterday while reading/reformatting the eric6
> plugin guide. Eric6 is a pure python app, but the eric6 ecosystem is almost
> completely different from Leo's. There is likely *no* clever way to use
> Leo's existing Qt code.  Everything would likely have to be rewritten.
>
> Embedding Leo in another IDE would create ripple effects that touch *all*
> of Leo's code.  These ripple effects would depend on arcane details of the
> particular IDE in which Leo is embedded.
>
>
ripple effects  <~~~ very right define,
appended one reason:
embedding others IDE ecosystem is hold one huge upstream into Leo's
ecosystem;
but the upstream ecosystem is out-control by ERK,
means for Leo's new feature can compatibility upstream ecosystem,
will ripple huge unnecessary work.


> It's impossible to know beforehand what the final design and code would
> look like. This makes such projects extremely risky. Quick prototypes won't
> significantly reduce the risk. Rather, they are likely to be wasted
> investments.
>
> *Endless distractions*
>
> Successful projects have limited focus, no matter how many devs are
> involved. Embedding Leo in another IDE would be a major, most unwise,
> commitment of time and energy for all Leo devs.
>
> Support would be endless. For example, leoBridge.py is a small module, but
> it has generated continuing and difficult issues. One of those issues
> required tricky futzing with gnx's when loading .leo files. Just recently I
> had to tweak that code again.
>
> Do we want to answer endless questions about how to build Pycharm, or
> whatever?  Do we want to tell people how to *use *Leo in other IDE's?
> Finally, do we want to complicate Leo's distros with javascript related
> matters?
>
> *Expensive advertising*
>
> My dream has been to promote Leo by offering its features in other
> environments. I'm ready to say now that this has always been a bad idea :-)
>
> I've learned in the past week or so that it's (usually) pretty easy to
> download and run other IDE's. People can and do use more than one IDE.
> People know where to find Leo.  Creating a Leo plugin in any other IDE
> would be an expensive and ineffective form of advertising.
>
> *Leo's strengths*
>
> In one of my first posts I said that just about everything Leo *shares*
> with Atom is inferior to Atom.  But this statement was *just plain wrong*. 
> Here
> are some common areas in which Leo excels:
>
> 1. Scripting. Most IDE's aren't scriptable at all, so technically my
> remarks don't apply ;-)
>
> 2. Plugins. Leo's plugin architecture is much simpler than eric6, and
> that's the easy case.
>
> 3. Searching. No other platform has Leo's clone find commands. etc.
>
> 4. Commands. Outline-oriented diffs exist nowhere else. etc.
>
> 5. Settings and configuration.  eric6 has a nifty gui representation of
> its settings, but Leo's settings are much more flexible:
>
> - Settings can apply to individual .leo files.
> - Settings nodes naturally contain arbitrarily verbose comments.
> - Users can organize settings trees as they like.
> - Plugins can add settings just by calling c.config.getBool, etc.,
> *without* adding to Leo's gui code.
>
> 6. Window system. Terry has made Leo's window system scriptable (in
> python!) and extensible.
>
> *Summary*
>
> Leo will remain a pure python app, scriptable in python.
>
> There is much to learn from eric6. I shall incorporate some of eric6's
> features into Leo's code base.
>
> Leo must have a plugin that supports Joe Orr's great work. This plugin
> will be worth *any* amount of work. Imo, this is the proper place to
> focus our time and energy.
>
> I am happy with these conclusions. They feel sane, sensible and safe. As
> always, they are provisional. We'll see how the subconscious reacts ;-)
> 

ENB: Serious doubts about embedding Leo

[Edward K. Ream]

The process of *considering* embedding Leo in another IDE has been one of 
the most useful things I have ever done.  I feel as if I have awoken from a 
deep slumber.  Atom, VSCode, eric6 and Pycharm/Intellij are all superb 
tools.  Building and using them, even briefly, has been eye opening.

But embedding Leo in another IDE would be a big mistake. This posts 
explains why.

This is a long post. To state my conclusions first:

- Embedding Leo in any IDE would be a huge and risky project.
- Such a project would distract us Leo devs, and burden us with endless 
support.
- Embedding Leo would be less useful than it might seem.
- Leo has its own strengths. Many don't translate easily to other IDE's.

See the summary for other conclusions.

*A huge and risky project*

Embedding Leo in any IDE would be much harder than it might appear at 
first.  At *minimum*, such a task would require an *entirely new* gui 
plugin for Leo. Such plugins have been the biggest projects in Leo's 
history.

This became obvious to me yesterday while reading/reformatting the eric6 
plugin guide. Eric6 is a pure python app, but the eric6 ecosystem is almost 
completely different from Leo's. There is likely *no* clever way to use 
Leo's existing Qt code.  Everything would likely have to be rewritten.

Embedding Leo in another IDE would create ripple effects that touch *all* 
of Leo's code.  These ripple effects would depend on arcane details of the 
particular IDE in which Leo is embedded.

It's impossible to know beforehand what the final design and code would 
look like. This makes such projects extremely risky. Quick prototypes won't 
significantly reduce the risk. Rather, they are likely to be wasted 
investments.

*Endless distractions*

Successful projects have limited focus, no matter how many devs are 
involved. Embedding Leo in another IDE would be a major, most unwise, 
commitment of time and energy for all Leo devs. 

Support would be endless. For example, leoBridge.py is a small module, but 
it has generated continuing and difficult issues. One of those issues 
required tricky futzing with gnx's when loading .leo files. Just recently I 
had to tweak that code again.

Do we want to answer endless questions about how to build Pycharm, or 
whatever?  Do we want to tell people how to *use *Leo in other IDE's? 
Finally, do we want to complicate Leo's distros with javascript related 
matters?

*Expensive advertising*

My dream has been to promote Leo by offering its features in other 
environments. I'm ready to say now that this has always been a bad idea :-)

I've learned in the past week or so that it's (usually) pretty easy to 
download and run other IDE's. People can and do use more than one IDE.  
People know where to find Leo.  Creating a Leo plugin in any other IDE 
would be an expensive and ineffective form of advertising.

*Leo's strengths*
   
In one of my first posts I said that just about everything Leo *shares* 
with Atom is inferior to Atom.  But this statement was *just plain wrong*. Here 
are some common areas in which Leo excels:

1. Scripting. Most IDE's aren't scriptable at all, so technically my 
remarks don't apply ;-) 

2. Plugins. Leo's plugin architecture is much simpler than eric6, and 
that's the easy case.

3. Searching. No other platform has Leo's clone find commands. etc.

4. Commands. Outline-oriented diffs exist nowhere else. etc.

5. Settings and configuration.  eric6 has a nifty gui representation of its 
settings, but Leo's settings are much more flexible:

- Settings can apply to individual .leo files.
- Settings nodes naturally contain arbitrarily verbose comments.
- Users can organize settings trees as they like.
- Plugins can add settings just by calling c.config.getBool, etc., *without* 
adding to Leo's gui code.

6. Window system. Terry has made Leo's window system scriptable (in 
python!) and extensible.

*Summary*

Leo will remain a pure python app, scriptable in python.

There is much to learn from eric6. I shall incorporate some of eric6's 
features into Leo's code base.

Leo must have a plugin that supports Joe Orr's great work. This plugin will 
be worth *any* amount of work. Imo, this is the proper place to focus our 
time and energy.

I am happy with these conclusions. They feel sane, sensible and safe. As 
always, they are provisional. We'll see how the subconscious reacts ;-)  
Please let me know *your* reactions.

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.