ENB: Serious doubts about embedding Leo
36 views
Skip to first unread message
Edward K. Ream
Feb 23, 2018, 4:37:32 AM2/23/18
to leo-editor
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
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
Zoom.Quiet
Feb 23, 2018, 5:05:36 AM2/23/18
to leo-e...@googlegroups.com
On Fri, Feb 23, 2018 at 5:37 PM, Edward K. Ream <edre...@gmail.com> 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 soooooo 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.
only one suggest:
this paper must insert into LeoDoc, maybe as FAQ?
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+unsubscribe@googlegroups.com.
To post to this group, send email to leo-e...@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!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!
Zoom.Quiet
Feb 23, 2018, 5:08:36 AM2/23/18
to leo-e...@googlegroups.com
On Fri, Feb 23, 2018 at 6:05 PM, Zoom.Quiet <zoom....@gmail.com> wrote:
On Fri, Feb 23, 2018 at 5:37 PM, Edward K. Ream <edre...@gmail.com> 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 soooooo quickly conform these points ;-)
confirm
just 2 week, ERK rebuild IDE world idea, Sayeahoo!
EKR <~ so sorry, i always type error abbreviation
Edward K. Ream
Feb 23, 2018, 10:05:58 AM2/23/18
to leo-editor
On Friday, February 23, 2018 at 4:05:36 AM UTC-6, Zoom.Quiet wrote:
> WoW soooooo 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.
> WoW soooooo 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.
> 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
Edward K. Ream
Feb 23, 2018, 10:28:24 AM2/23/18
to leo-editor
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
#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
Reply all
Reply to author
Forward
0 new messages