On Fri, Feb 23, 2018 at 5:37 PM, Edward K. Ream <edream...@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
> - 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
> 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
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
> *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?
> *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*.
> 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.
> 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.
only one suggest:
this paper must insert into LeoDoc, maybe as FAQ?
> 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 email@example.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当歌!
KM keep growing environment culture which promoting organization learning!
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.