Re: Leo in 2017

[Edward K. Ream]

On Sunday, December 25, 2016 at 8:15:24 AM UTC-5, Sr U wrote:
>
> Happy Holidays Edward!  
>

Thanks you.  Sorry for the delay in responding.  Somehow your response got 
lost in my inbox. 

>
> I want to encourage your "Less Said the Better" (TM:-) initiative, in 
> particular.
>

Thanks.  I think it will make a big difference.
 

> If I understand correctly, you might attempt to take a newbie by the hand 
> to go from zero to "writing" a small but complete python program in five 
> minutes or so?
>

Something like that :-)  We want to show people that *all* of Leo's central 
ideas are, in fact, quite simple.  We want to present those central ideas 
*clearly*, with no extraneous ideas. We don't want to freak people out. 
 

> Alternatively you might start by having a new user import a small working 
> python program and then "factor" it in Leo to show the outline ... and then 
> make a few small tweaks before executing the program from within Leo?   
> (Correct me if I have your vision wrong and am merely conflating my wish 
> list with your vision)
>

This might work.  I hadn't thought of this.  "The less said the better" 
applies to all aspects of Leo's documentation, not just the scripting 
parts.  But yes, those parts typically have the most confusing details. 

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: Leo in 2017

[Edward K. Ream]

On Saturday, December 24, 2016 at 6:16:41 AM UTC-5, Edward K. Ream wrote:

The last two years have seen @clean and the clone-find commands.  Both are 
> game changers. My *goal *for the new year is create something similar.
>

*Design and checking*
>
> After spending considerable time writing the make-stub-files 
>  script, I have never used 
> mypy . I'll probably play around with checking 
> next year.  Programmers have not begun to use big data to validate/improve 
> their programs...
>

I recently realized that pep484  
contains a suggested syntax for type-comments 
.
  
This would allow Leo to use mypy.  To do this, I will adapt the 
make-stub-files script so it inserts those comments.

EKR

-- 
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: Leo in 2017

[Edward K. Ream]

​​
​​


On Tue, Dec 27, 2016 at 10:01 PM, ne1uno  wrote:

> I had opportunity to use the mercurial shelf in TortoiseHG today.
> say you want to revert the working tip but don't want to commit.
> you have a patch for a file or a few files and shelve them
> revert update then un-shelve the patches and back in business.
>

​Git stash works much the same way.  I often "stash" code away in Leo.
This usage of Leo is more flexible and easier to use than git stash.​


I see clamoring for multiple body's in Leo
>

​A recent Aha, which I haven't gotten around to writing up, is that
comparing body text in separate windows is usually more convenient.  As a
result, I have even less use for multiple body panes than before.  Imo, one
can make a (strong?) case for removing all that ugly code completely.

what about multiple outlines? or is that already being done?
>
​
It was done many years ago, in the C++ version of Leo.  The feature was
called "cloned windows".  It was inspired by a similar feature in (iirc)
Apple's Yellow Box dev system.  It was cool, but totally useless.  I
removed it (don't remember when) and have never ever regretted it.

obviously lots of work comparing two revisions and then somehow applying
> ​ ​
> the patches.
>

​I have just re-read the original diff thread
.​ The real
Aha, which came after the first post, is that @auto does work that no other
diff program does, namely to *consistently* split the to-be-compared files
into nodes.

This is a big deal, and we should keep it in mind.  Having said that, I
have been having my doubts that Leoinistas would actually benefit as much
as I first thought.

The short form of the argument is that programmers use diffs only as
reminders (when creating git checkin logs) or in emergencies (say after git
bisect has found a worthy bug).  Most other times, we don't think in terms
of diff, or use diff.  Instead, we use higher-level mental representations.


> even for the one file I was working on with 3 minor changes
> ​ ​
> I managed to lose 2 of the edits by the time I got to apply the patch.
> ​ ​
> you can get the diffs but files can radically change as you go back in
> time.
>

​Yeah.  Patches are reliable only temporarily. Ditto (I think) for git
merge requests.
​


> maybe if such a tool existed you would find ways to use it?
>

​Maybe, but I have to be more convinced *before* I start coding.​



is code coverage checking a done deal in python? any language?
>

​Yes.  Googling "python coverage" yields this page.
​

​It is interesting code.  In the past I've studied it, and modified it, in
detail.​


a test outline on the left and source outline on the right
> uncovered code highlighted. maybe more tests generated.
> https://wiki.python.org/moin/CodeCoverage
>

​The gui representation of diffs/coverage, is important.  coverage.py
generates html(!)​


don't forget the substantial non programmer Leo user population!
> there might be a use for test driven writing?
>

​Intriguing ​

​thought.
​

> create an outline
> then analyze the nodes, do they make sense.
> going the other way, take a bunch of text and generate
> headlines. is a free form text importer
> ​​
> possible? useful?
>

​Once again, we have only begun to explore what is possible with Leo ;-)

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: Leo in 2017

[ne1uno]

I had opportunity to use the mercurial shelf in TortoiseHG today.
say you want to revert the working tip but don't want to commit.
you have a patch for a file or a few files and shelve them
revert update then un-shelve the patches and back in business.

I see clamoring for multiple body's in Leo
what about multiple outlines? or is that already being done?

obviously lots of work comparing two revisions and then somehow applying
the patches. even for the one file I was working on with 3 minor changes
I managed to lose 2 of the edits by the time I got to apply the patch.
you can get the diffs but files can radically change as you go back in time.
maybe if such a tool existed you would find ways to use it?

is code coverage checking a done deal in python? any language?
a test outline on the left and source outline on the right
uncovered code highlighted. maybe more tests generated.
https://wiki.python.org/moin/CodeCoverage

don't forget the substantial non programmer Leo user population!
there might be a use for test driven writing? create an outline
then analyze the nodes, do they make sense.
going the other way, take a bunch of text and generate
headlines. is a free form text importer possible? useful?


On Saturday, December 24, 2016 at 6:16:41 AM UTC-5, Edward K. Ream 
wrote:The last two years have seen @clean and the clone-find commands.  
Both are game changers. My *goal *for the new year is create something 
similar.

The *strategy *will be to focus on problems that we have learning or using 
Leo.  Some possibilities:



*Learning about Leo*The Programming with Leo 
 tutorial must be 
rewritten, following the "less said the better" principle. I'll start with 
motivating @file and @others.  Everything else is details.

I am considering a series of "Looking over Edward's shoulder" tutorials.  
Instead of slideshows or videos, it may be more effective to throw out a 
few haiku-like invitations for discovery, following the how to learn Leo 
post . 
Yes, Leo has a gazillion features, but the basics of Leo are simple, and 
there aren't many of them.

*Editing*

Leo might benefit from a temporary vim mode.  This should be easy to do, 
and it might be useful in some situations.  Leo might also benefit from a 
vim-like "dot" command.

I am having my doubts that a super-duper outline-based diff 
 is going 
to be useful. The only time I ever use git diff is when creating a checkin 
log. Still, I'll investigate a bit further.

As always, I'll be looking for ways to better integrate Leo with vim, 
emacs, jupyter, etc.

*Testing*

The TDD advances 
, have 
stimulated further thoughts. More improvements may follow.

Leo is a uniquely friendly environment for unit testing.  For example, one 
could imagine a short script that would generate unit tests for all 
commands, or all methods in a file or class.

*Design and checking*

After spending considerable time writing the make-stub-files 
 script, I have never used 
mypy . I'll probably play around with checking next 
year.  Programmers have not begun to use big data to validate/improve their 
programs...

*Understanding*

The biggest payoff may come from enhancing Leo's unique strength, namely 
understanding computer programs, or other complex data.  Advances in this 
arena will be difficult (impossible) to duplicate in other programs.

That's all for now.  All comments welcome.

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: Leo in 2017

[Sr U]

Happy Holidays Edward!  

I want to encourage your "Less Said the Better" (TM:-) initiative, in 
particular.  If I understand correctly, you might attempt to take a newbie 
by the hand to go from zero to "writing" a small but complete python 
program in five minutes or so?   Alternatively you might start by having a 
new user import a small working python program and then "factor" it in Leo 
to show the outline ... and then make a few small tweaks before executing 
the program from within Leo?   (Correct me if I have your vision wrong and 
am merely conflating my wish list with your vision)

Anyway, I think something like that could have a huge payoff.   It should 
allow python programmer wannabes, especially, to completely sample what Leo 
can provide that other editors/IDEs cannot in just 5-10 minutes.   
Following a vehicle sales analogy it would be enough of a hands-on real 
world context so the user would feel comfortable to drive Leo "home" on 
their own.  KISS.

AFTER the intro you could invite the newbie to add some changes or further 
factor the code base on their own...or "come back tomorrow" to learn how to 
do "fancy" things (like global find, cloning, myriad @ options, etc).

Using again the car sales analogy: you want to get the "customer" to drive 
the car home TODAY; and you don't want them "thinking" overnight nor 
visiting other car lots first.

There are so many editors out there -- but I've not seen another 
programmer's tree editor to support top down development and code 
factoring.  I think getting potential new users invested very, very rapidly 
with a small but "good enough to drive home" subset of Leo commands will 
grab a lot of new programmers and get them off to a solid start before they 
can get distracted from their own best interest! :-)

Know sales basics: get  "kids" fully engaged with the new "toy" and get 
them to use it and own it before intimidating them too much with all the 
confusing cockpit choices and power of the jet fighter-bomber cockpit they 
are ACTUALLY purchasing. ;-/

I still don't know how to use Leo to begin developing a python program in 
the coursera intro python course I am signed up for.  The course instructor 
is encouraging me to just use IDLE "for now" but I would prefer to get 
started with a better ... habit?

Sorry for the redundancy and poor editing of my message. It is 5 AM and my 
insomnia is running out!

On Saturday, December 24, 2016 at 3:16:41 AM UTC-8, Edward K. Ream wrote:
>
> The last two years have seen @clean and the clone-find commands.  Both are 
> game changers. My *goal *for the new year is create something similar.
>
> The *strategy *will be to focus on problems that we have learning or 
> using Leo.  Some possibilities:
>
>
>
> *Learning about Leo*The Programming with Leo 
>  tutorial must be 
> rewritten, following the "less said the better" principle. I'll start with 
> motivating @file and @others.  Everything else is details.
>
> I am considering a series of "Looking over Edward's shoulder" tutorials.  
> Instead of slideshows or videos, it may be more effective to throw out a 
> few haiku-like invitations for discovery, following the how to learn Leo 
> post . 
> Yes, Leo has a gazillion features, but the basics of Leo are simple, and 
> there aren't many of them.
>
> *Editing*
>
> Leo might benefit from a temporary vim mode.  This should be easy to do, 
> and it might be useful in some situations.  Leo might also benefit from a 
> vim-like "dot" command.
>
> I am having my doubts that a super-duper outline-based diff 
>  is going 
> to be useful. The only time I ever use git diff is when creating a checkin 
> log. Still, I'll investigate a bit further.
>
> As always, I'll be looking for ways to better integrate Leo with vim, 
> emacs, jupyter, etc.
>
> *Testing*
>
> The TDD advances 
> , have 
> stimulated further thoughts. More improvements may follow.
>
> Leo is a uniquely friendly environment for unit testing.  For example, one 
> could imagine a short script that would generate unit tests for all 
> commands, or all methods in a file or class.
>
> *Design and checking*
>
> After spending considerable time writing the make-stub-files 
>  script, I have never used 
> mypy . I'll probably play around with checking 
> next year.  Programmers have not begun to use big data to validate/improve 
> their programs...
>
> *Understanding*
>
> The biggest payoff may come from enhancing Leo's unique strength, namely 
> understanding computer programs, or other complex data.  Advances in this 
> arena will be difficult (impossible) to duplicate in other programs.
>
> That's all for now.  All comments welcome.
>
> Edward
>

-- 

Leo in 2017

[Edward K. Ream]

The last two years have seen @clean and the clone-find commands.  Both are 
game changers. My *goal *for the new year is create something similar.

The *strategy *will be to focus on problems that we have learning or using 
Leo.  Some possibilities:



*Learning about Leo*The Programming with Leo 
 tutorial must be 
rewritten, following the "less said the better" principle. I'll start with 
motivating @file and @others.  Everything else is details.

I am considering a series of "Looking over Edward's shoulder" tutorials.  
Instead of slideshows or videos, it may be more effective to throw out a 
few haiku-like invitations for discovery, following the how to learn Leo 
post . Yes, 
Leo has a gazillion features, but the basics of Leo are simple, and there 
aren't many of them.

*Editing*

Leo might benefit from a temporary vim mode.  This should be easy to do, 
and it might be useful in some situations.  Leo might also benefit from a 
vim-like "dot" command.

I am having my doubts that a super-duper outline-based diff 
 is going 
to be useful. The only time I ever use git diff is when creating a checkin 
log. Still, I'll investigate a bit further.

As always, I'll be looking for ways to better integrate Leo with vim, 
emacs, jupyter, etc.

*Testing*

The TDD advances 
, have 
stimulated further thoughts. More improvements may follow.

Leo is a uniquely friendly environment for unit testing.  For example, one 
could imagine a short script that would generate unit tests for all 
commands, or all methods in a file or class.

*Design and checking*

After spending considerable time writing the make-stub-files 
 script, I have never used 
mypy . I'll probably play around with checking next 
year.  Programmers have not begun to use big data to validate/improve their 
programs...

*Understanding*

The biggest payoff may come from enhancing Leo's unique strength, namely 
understanding computer programs, or other complex data.  Advances in this 
arena will be difficult (impossible) to duplicate in other programs.

That's all for now.  All comments welcome.

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.