how to run a script when Leo starts

[Phil]

I want a script to run every time I start Leo. How can I do this?

Thanks,
Phil

-- 
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: Cleaning imported javascript headlines

[vitalije]

many (most?) problems with imports can be fixed by hand in the generated 
> @clean tree.

Yes, I am aware of this. But it turned out quite often for me that amount 
of work needed for that manual fixing exceeds the amount of work needed to 
split file by hand in the first place.

I would not argue that files from some (possible many) other languages can 
be imported properly. But there is not so small number of languages like 
javascript which can't be imported satisfactorily. Javascript itself has a 
number of dialects, scala is another example. Groovy also comes to my mind. 
They have so rich syntax that I really doubt that Leo in its current form 
can handle them very well. I haven't tested it, but every time I used 
import I ended up doing lot of manual reshaping and quite often I abandoned 
the whole process and started all over again with manual splitting file.

Vitalije

-- 
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: @rclick in myLeoSettings.leo not generating commands in work files

[Edward K. Ream]

On Fri, Feb 23, 2018 at 9:59 AM, Kent Tenney  wrote:

> @rclick buttons defined in myLeoSettings.leo work fine in work files,
> and  <@rclick command name> works fine in the myLeoSettings.leo
> file, but in the work files,  <@rclick command name> is unknown.
>
> Before submitting a bug/enhancement request, can anyone else
> comment on whether they also see this?
> I'm leery of my issues being due to personal cruft.
>

​Please submit a bug report.  You've done your homework, whatever the
outcome may be.

Please remember that I often don't have time to evaluate immediately
whether something should be an issue or not.  When in doubt, file an issue
so that it will remain on the radar.  This allows me to keep my inbox clean.

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: How did I came across Leo?

[Edward K. Ream]

On Fri, Feb 23, 2018 at 11:35 AM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

​> ​
So, my path was Python -> Zope -> Leo -> Outlining for Literate Programming
-> Writing -> Pharo, Roassal -> Reproducible research and data storytelling
and visualization -> Grafoscopio.

​It's been great fun reading these comments.  I may create a new section in
the docs for them.

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: Cleaning imported javascript headlines

[Edward K. Ream]

On Friday, February 23, 2018 at 10:22:55 AM UTC-6, vitalije wrote:

Cleaning generated headlines is just a part of the problem. More serious 
> problem is choosing what should go in to single node.
>

I agree completely.
 

> As far as I am concerned, I would much prefer to have a toolbox with 
> several commands to help me importing files on my own. I wrote about that 
> idea here 
> . I 
> don't know when (and if) I would have time to write such a plugin. Solving 
> this serious problem (* importing external source files) in fully automatic 
> but satisfactory way IMHO must involve writing a proper lexer/parser 
> functions at least for .js .jsx, .ts .tsx files. That seems to be a lot of 
> work, so I believe more likely is that I would pursue this simpler idea - a 
> plugin with handful of universal functions for manipulating source code, 
> that user can use to reshape code any way he/she likes. That would work for 
> all kinds of source files.
>

Remember that all importers have a post pass in which they are free to 
alter the already generated nodes.

Javascript is probably unique in all commonly-used languages in not having 
a proper, *always used*, syntax for generating classes, functions and 
methods.  This makes the problem *much* harder for js than it is for all 
other languages.

Afaik, there are few if any problems with other languages.  Once in a while 
the python importer has troubles with if statements at the top level 
interacting with decorators.  That's about it.  Tweaking the python post 
pass should fix this, but it's a low priority item.

So yes, have at it if you will.  But remember that many (most?) problems 
with imports can be fixed by hand in the generated @clean tree.

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: How did I came across Leo?

[Offray Vladimir Luna Cárdenas]

Hi,

I came about Leo because I was interested in Learning Python and some
forum said that Leo, not Zope, was a superb showcase for this language
and then I found that it supported a form of literate programming, which
I was already interesting into. I started to use it almost exclusively
for writing, not for programming, from note keeping to even draft of my
thesis, since 2005, when I found Leo, to 2015 and then I found Pharo and
Roassal and the idea of software as a graph[1] and I decided to create
my own outliner with ideas of Leo, Jupyter, Smalltalk and others. These
days I still use Leo for quick notes and probably I would use it again
to deconstruct some large script or textual program.  So, my path was
Python -> Zope -> Leo -> Outlining for Literate Programming -> Writing
-> Pharo, Roassal -> Reproducible research and data storytelling and
visualization -> Grafoscopio. Of course, some parts were traversed in
parallel and I still try to combine ideas and communities from several
places.

[1] https://vimeo.com/94724841

Cheers,

Offray

On 21/02/18 20:02, Satish Goda wrote:
> It has been almost 14 months since I discovered Leo and today I
> recalled how I found it.
>
> I was searching GitHub for the term "QWidgetAction" and came across
> its usage in Leo codebase.
>
> And then curiosity killed the cat and I was curious about Leo and read
> about it and downloaded it as well.
> -- 
> 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: Cleaning imported javascript headlines

[vitalije]

  There are problems assigning lines to nodes.
>
> Edward
>
Precisely  

-- 
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: Cleaning imported javascript headlines

[Edward K. Ream]

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

I am working on improvements [to .  Please hold suggestions for a bit.
>

Rev 0deba52 completes the present round of work on this project. There are 
no problems that I can see with the *headlines* when importing leovue/src.  
There are problems assigning lines to nodes.

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: Joe, building LeoVue fails for me on Windows and Ubuntu

[Zoom.Quiet]

OT: Critical Linux filesystem permissions are being changed by latest
version · Issue #19883 · npm/npm
https://github.com/npm/npm/issues/19883

god bless NPM user

On Tue, Feb 20, 2018 at 6:56 AM, Edward K. Ream  wrote:
> On Monday, February 19, 2018 at 11:42:11 AM UTC-6, Edward K. Ream wrote:
>
>> I did all the installs in separate consoles. These consoles tell me
>> everything except the order in which they were installed ;-) Hmm, maybe I
>> should add a time stamp to the console prompts...
>
>
> There's too much cruft in the approach.  Imo, it's better just to keep an
> accurate log of the commands I issued.
>
> I ended up reinstalling the leovue folder four or five times. It would just
> add to the confusion if I kept lots of consoles around.
>
> 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.



-- 
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: Cleaning imported javascript headlines

[Edward K. Ream]

On Friday, February 23, 2018 at 9:42:24 AM UTC-6, Edward K. Ream wrote:

> The javascript importer now defines [clean_headline] this way:

I am working on improvements.  Please hold suggestions for a bit.

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: Cleaning imported javascript headlines

[vitalije]

Cleaning generated headlines is just a part of the problem. More serious 
problem is choosing what should go in to single node. As far as I am 
concerned, I would much prefer to have a toolbox with several commands to 
help me importing files on my own. I wrote about that idea here 
. I 
don't know when (and if) I would have time to write such a plugin. Solving 
this serious problem (* importing external source files) in fully automatic 
but satisfactory way IMHO must involve writing a proper lexer/parser 
functions at least for .js .jsx, .ts .tsx files. That seems to be a lot of 
work, so I believe more likely is that I would pursue this simpler idea - a 
plugin with handful of universal functions for manipulating source code, 
that user can use to reshape code any way he/she likes. That would work for 
all kinds of source files.
Vitalije

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

@rclick in myLeoSettings.leo not generating commands in work files

[Kent Tenney]

@rclick buttons defined in myLeoSettings.leo work fine in work files,
and  <@rclick command name> works fine in the myLeoSettings.leo
file, but in the work files,  <@rclick command name> is unknown.

Before submitting a bug/enhancement request, can anyone else
comment on whether they also see this?
I'm leery of my issues being due to personal cruft.

I'll push on this because I think the button/command capability in Leo
is really what sets it apart.

tiny bits of code resulting in new capability, both clickable and
typeable, available in any leo file in the same directory
with virtually ZERO learning curve ...  amazeballs

Thanks,
Kent

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

Cleaning imported javascript headlines

[Edward K. Ream]

Leo's import system has many strengths.  The most important is that code 
will almost always import correctly even if the resulting nodes aren't even 
close to optimal.  This is particularly important for javascript, where 
coding styles vary so widely.

After generating nodes, the import system calls the clean_headline method.  
The base Importer class defines a clean_headline as follows:

def clean_headline(self, s, p=None):
'''
Return the cleaned version headline s.
Will typically be overridden in subclasses.
'''
return s.strip()

The javascript importer now defines this method this way:

clean_regex_list1 = [
re.compile(r'\s*\(?(function\b\s*[\w]*)\s*\('),
re.compile(r'\s*([\w]+\:\s*\(*\s*function\s*\()'),
re.compile(r'\s*(?:const|let|var)\s*(\w+\s*(?:=\s*.*)=>)'),
]
clean_regex_list2 = [
re.compile(r'(.*)\((\s*function)'),
re.compile(r'(.*\=)(\s*function)'),
]

def clean_headline(self, s, p=None):
'''Return a cleaned up headline s.'''
s = s.strip()
# Don't clean a headline twice.
if s.endswith('>>') and s.startswith('<<'):
return s
for ch in '{(=':
if s.endswith(ch):
s = s[:-1].strip()
# First regex cleanup.
for pattern in self.clean_regex_list1:
m = pattern.match(s)
if m:
s = m.group(1)
break
# Second regex cleanup.
for pattern in self.clean_regex_list2:
m = pattern.match(s)
if m:
s = m.group(1) + m.group(2)
break
s = s.replace('  ', ' ')
return g.truncate(s, 100)

This isn't perfect, but is much better than previous versions.  I encourage 
Vitalije or anyone else to suggest improvements.

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