Wanted: missing features from VS code, Atom, etc

[Edward K. Ream]

I have just created #906: Info: About Leo's future 
. This reminds me not 
to do stupid things, like rewriting Leo's core in another language, or 
trying to embed Leo in another IDE.

I have also created #907: Info: Borrow key features from other IDE's and 
editors.  This reminds 
me to keep studying other IDE's and to borrow/steal/adapt ideas from them 
freely. Please feel free to add two or three items here, or in #907. 

This morning I played with VS Code 

 
for a few hours.  There is a lot of good stuff there, but not so much as to 
be intimidating. Here are a few impressions.

*Settings*

Superficially, VS Code settings may look easier to change. In fact, Leo's 
settings are more flexible. They certainly are easier to organize in Leo.

I did like the way VS Code handles key bindings.  In particular, settings 
can be associated with *events*, not just panes as in Leo. This might be a 
new direction for Leo.

*Non-outline tabs*

Many IDE's, including VS Code, can display web pages using then entire 
window.  Imo, this would be a great new feature for Leo. For example, the 
1.23.1 
release notes  actually look 
better in the VS Code app than on the web.

But the real idea is to allow the VR pane to occupy the entire window, that 
is, an entire tab.  This would allow Leo to display .md files "natively" in 
the entire window, rather than squashed into whatever space is allocated to 
the VR pane.

Similarly, one of Kent's favorite requests, a "flattened" view of an entire 
file, would also be a good candidate for displaying in the full window.  
And so on.

*Pylint*

VS Code has a setting to run Pylint whenever saving a .py file.  Leo could 
have this also.  VS Code uses a separate pane to display pylint 
complaints.  Iirc, Terry's clickable links apply only to syntax errors and 
pyflakes errors.  Pylint errors should also create clickable links, if they 
don't already.

*Other panes*

Most IDE's support lots and lots of other views.  It's an open question how 
useful these would be in Leo.

*Integrated debugger*

This is a big hole in Leo's feature set.  Imo, single-stepping through code *in 
Leo's outline* would be a good feature to have. BTW, the recent work on 
jedi auto-completion shows how to associate line numbers in the external 
file with lines in each node of the file.  It's actually very easy and fast 
to do, which I had not realized until this week.

*Summary of features*

I have just created #908: Info: Summary of Leo's features 
 as a stub. We need a 
central place to summarize Leo's strengths, and plans for improvement.  
This might eventually find it's way onto Leo's web site.

*Summary*

Other editors and IDE's are a rich source of inspiration.  We Leo devs can 
be happy about this state of affairs.  It's a lot easier to 
borrow/steal/adapt ideas from others than it is to have other IDE's mimic 
Leo's essential features.

Please feel free to add your ideas here, or directly in #907 
.

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: @data abbreviation documentation

[Rob]

Got it, thanks for the clarification.

Rob...

On Monday, May 21, 2018 at 9:08:09 AM UTC-4, Edward K. Ream wrote:
>
> On Tue, May 15, 2018 at 8:19 AM, Rob  
> wrote:
>
>> Hmm, I still see the old comments.
>>
>
> ​Try 4a66d753d in devel.
>
> 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: Please read: "You can do that if..."

[Edward K. Ream]

On Monday, May 21, 2018 at 7:01:22 AM UTC-5, Edward K. Ream wrote:

Transforming "We *can't* do x because of y" into "We *can *do x if z" is a 
> brilliant, and brilliantly simple, way of encouraging innovation while 
> setting proper limits.
>

I suspect all successful engineers do something like this implicitly.  
Making this explicit has at least these benefits:

1. It makes this technique available to everyone.
2. It removes roadblocks to creative thinking.
3. It acts as a strong stimulus to creativity and the subconscious mind.

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: @data abbreviation documentation

[Edward K. Ream]

On Tue, May 15, 2018 at 8:19 AM, Rob  wrote:

> Hmm, I still see the old comments.
>

​Try 4a66d753d in devel.

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: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Sun, May 20, 2018 at 1:08 PM, vitalije  wrote:


> To be fair, I must point out that Leo is performing also undo/redo logic
> which my prototype still doesn't. But taking a full snapshot of the tree in
> the new model was measured before and it used to take about 20ms, for the
> outline of about 8300 nodes (LeoPyRef.leo).
>
> With that snapshot time added new model is still at least 100 times faster
> than Leo in the worst case (for Leo) and about 6 times faster in the
> easiest case for Leo (with all nodes collapsed).
>

​I look forward to seeing the code.  Is it available?
​

> Even if the changing Leo tree is O(1) operation, it seems that overall
> operation is much worse.
>

​One of my dreams is to support huge outlines, so that, for example, one
could imagine the human genome project using Leo outlines.
​

> What still remains to be done in my prototype is importing files, reading
> at-auto files which is wide area considering how many different languages
> Leo supports. I will try to make python, markdown and rest importers next
> because they are used in Leo, Leo's installation folder have files that I
> can use for the testing and comparing with the Leo importers.
>
> For the javascript importer I have an idea to use node modules for parsing
> numerous javascript dialects. Existing node modules like babel have already
> solved the problem of different dialects and can produce necessary data for
> Leo to create well shaped outline. And those node modules work very fast.
> They analyze hundreds of js files in less than 10s.
>

​I look forward to seeing these importers.

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.

Please read: "You can do that if..."

[Edward K. Ream]

My brother-in-law Ray Reed is a retired Boeing engineer.  While chatting at 
Linda's wedding dinner Friday night he related the following story.

His team was working on a new plane, the 787, iirc. The team was given a 
"blank sheet of paper", that is, permission to try anything, without 
constraints. That's exceedingly rare in engineering.

The guiding principle, used by both management and engineering, was that 
instead of saying "We *can't* do x, because of y", people would say, "We *can 
*do x, if z".  Now z might seem impossible, but the new viewpoint 
encourages innovation.  Now the question becomes, "how can we do z?", which 
may lead to further statements like, "we can do z if z1, z2, z3".

So a tree of interesting questions arises. And, just like in Leo's history, 
some "sideways" insight might affect the entire tree. And that's what 
happened.

*Summary*

Transforming "We *can't* do x because of y" into "We *can *do x if z" is a 
brilliant, and brilliantly simple, way of encouraging innovation while 
setting proper limits.

We can apply this to Leo's development as follows. We can do *anything*, 
provided that:

1. Changes do not affect Leo scripts in any significant way.

2. There are no other adverse affects.

Point 2 is the "two steps forward and one step backward is not good enough" 
principle.

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.