Re: Next-gen edit pane enabling org-mode and jupyter like experiences, and much more

['Terry Brown' via leo-editor]

Thanks for these thoughts.  It might be possible to wrap 3-5 of the new
editor panes in a vertical scrolling view such that they appear to be
an endless series... interesting thought.

Not sure if you use Windows or Unix, but for the latter the leoscreen
plugin offers quite good integration with any command line driven
environment - shell, R, SQL, Python, although that's a bit redundant :-)

Cheers -Terry

On Fri, 10 Feb 2017 12:51:34 -0800 (PST)
john lunzer  wrote:

> Terry, since you are working on Leo's next generation edit pane
> anyway I thought I'd at least throw the idea out there to see if it
> resonated with where we'd like to take Leo's body pane. Edward, I'd
> like to get your take as well as it could impact many goals coming up.
> 
> I call it "continuous edit mode"
> 
> The idea is that the body/edit pane would show node content from
> multiple nodes delineated with a special non-editable stylized
> heading + vertical divider. The nodes it would take body content from
> would be N visible nodes plus or minus the currently selected node.
> If you move your cursor (up/down arrow) past the editable text for
> one node to the content of the next node it will automatically
> highlight that node in the tree without taking focus away from the
> body. Content from other nodes could be optionally dimmed (with
> shortcutted toggle command) to retain the aspect of focus that Leo
> currently enables by viewing node body content in isolation. 
> 
> The benefits/implications of this type of body editor mode:
> 
>- Faster workflow. Switching back and forth between the body is
> not a big deal but a continuous edit pane would offer a natural
> method of moving to the next node without leaving the body editor or
> using shortcuts. Page down/up would always end at the content of the
> currently selected node without moving to the content of the next
> node then up/down arrow could be used to move to the content of the
> previous/next node. 
>- This could provide a flat view of the tree similar to what you
> see in emacs' org-mode. In essence a type of org-mode emulation,
> which could help realize a lot features Edward wants to bring from
> emacs' org-mode. The flat view in general can help give a more global
> understanding of the code.
>- A mechanism to create a Jupyter like experience where you can
> create a new "input" node which might be automatically given a node
> heading "[1] in", type the code you want in the node and and execute
> it which would create a node directly below the current node with the
> heading "[1] out" and the output of the previous command and also
> automatically create a new empty node with the heading "[2] in".
>- Building off the previous example, any type of continuous
> input/output workflow. I badly want to be able to simulate a shell
> inside Leo. This type of body editor could facilitate the writing of
> such "shell" plugins. 
>- A gentler less shocking transition to Leo for new users who are
> used to "flat" editors. Once they get used to how nodes work.
>- You could use abbreviations or custom commands in the body to
> create new nodes from the body. Say you type "My next node" by itself
> on a line in the body and then press the keys for your shortcut to
> "new-node-from-line" which would create a new node below your current
> one. The stylized heading shows up in your body editor below the
> content of the current node. You could then arrow down to switch to
> the next node, never leaving the body editor but getting the full
> benefits of a tree structured document.
>- I envision clone-find-all and clone-find-flat becoming even more 
>powerful search tools as you quickly move through the content of
> the found nodes with just page up/down and arrow up/down.
> 
> The generic aspect of such a view mode enables emulating experiences
> from other editors/environments and I believe can be exploited to
> many other user friendly gains 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.

Re: Chapter-Select command

[lewis]

OK thanks. A simple example in the docs would be most helpful. For example
@chapter
   @chapter One
   @chapter Two


Either the "Using Chapters" 
http://leoeditor.com/outlines.html#using-chapters documentation is out of 
date or some of the commands are broken.

*- The chapter-create command creates an @chapter node and populates it 
with a single node.*
The chapter-create command doesn't create a chapter. I tried these options:
Alt-X chapter-create  
Alt-X chapter-create-Five  
Alt-X chapter-create Five  
 however nothing happens at all.

*- The chapter-remove command deletes the currently selected chapter.*
I selected chapter, then
Alt-X chapter-remove  Nothing happens. 

Also, focus does not remain on the selected chapter, or on selecting  the 
main chapter icon - focus returns to where you were in the non-chapter part 
of the leo outline.
Example: select Chapters icon bar: Two (you are in chapter Two), now select 
Chapters icon bar: main (You aren't taken to the main @chapter top node)
This focus switching behaviour is unexpected.

Regards
Lewis


On Saturday, February 11, 2017 at 2:01:12 AM UTC+11, Edward K. Ream wrote:
>
>
> ​The chapter-select commands works properly. The only valid values are 
> chapter names:
>
> @chapter name 1
> @chapter name 2
>

-- 
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: About org mode

[jkn]

Hi Edward

FWIW (I haven't watched the whole video yet), the early parts of this 
reminded me a lot of the 'Origami' Editor for the Transputer Development 
System (TDS)

The Tab/Alt-TAB action of Origami to enter/leave 'integrated' outlines was 
terribly fast and intuitive.

Origami is history these days but it might still be worth a play for 
insight. I ill try to find a link to a binary which works on recent systems.

Regards
Jon N




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

About org mode

[Edward K. Ream]

I finished watching this superb video about org-mode 
 earlier today.  I took 
copious notes.

It has inspired many thoughts, and will continue to do so. I expect this 
conversation to be long lasting and fruitful.  Some *brief* first thoughts:

1. The demo looked off the cuff. Each topic had its own org-mode "page" 
containing the script for that page. It look like Camtasia did the post 
production. This is a perfectly reasonable, perhaps superior, alternative 
to totally controlled demos using demo-it.el or demo.py.

2. After the first few minutes, the presentation had almost nothing to do 
with outlines!

3. The demo shows that Leo must have better rendering *in the body pane, 
not* a separate rendering pane.

4. Imo, the real difference between Leo and Emacs lies differing approaches 
to multiple buffers and screen real estate. Both ways have pluses and 
minuses.  Discussing the nuances should be fascinating.

5. Leo can (and will) soon have *everything* that org-mode has. Otoh, that 
will likely not be enough to cause an exodus from Emacs to Leo.  Still, Leo 
has features that org-mode will likely never have. It reminds me of the 
song, Anything you can do, I can do better 
.

More to come later.

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: Warning: imp.reload hurts super and TDD

[Edward K. Ream]

​​On Fri, Feb 10, 2017 at 12:16 PM, john lunzer  wrote:
​
​

Edward, doesn't that statement just scream "*something is wrong with this*"
> to you?
>

​Heh.  I spend way too much time on python 2/3 compatibility.

Alas, it works both ways.​

​For instance, egged on by org-mode, I found this script

for converting LaTeX to a picture.  It's a Python 2 script, so to make it
work on 3 I had to change the import to:

if g.isPython3:
from io import BytesIO as StringIO
else:
from cStringIO import StringIO

This kind of thing is a *daily* irritation.  It won't go away if we require
Python 3.

There are a lot of things that I like about Python 3, but two things truly
piss me off:

1. The distinction between str and unicode in Python 2 has morphed into the
distinction between bytes and str. How is that *any* kind of improvement?
Worse, str has flipped its meaning!

2. The introduction of incompatible libraries is infuriating. *Adding* new
libraries would have been fine. Removing the old libraries was an insult.

I envy those with the luxury of creating Python 3 code, but these
kinds of *meaningless
*differences will be with us literally forever.  Python 2 isn't going away
in my lifetime, I would guess.

Hmm.  Rather than get stuck in helpless rage, Leo should have a 2-to-3
command that would automatically convert selected text from Python 2 to 3.
Maybe by pasting to the clipboard...

For sure I am going to check out what 2to3 suggests for:

from cStringIO import StringIO

It had better be good.

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.

Next-gen edit pane enabling org-mode and jupyter like experiences, and much more

[john lunzer]

Terry, since you are working on Leo's next generation edit pane anyway I 
thought I'd at least throw the idea out there to see if it resonated with 
where we'd like to take Leo's body pane. Edward, I'd like to get your take 
as well as it could impact many goals coming up.

I call it "continuous edit mode"

The idea is that the body/edit pane would show node content from multiple 
nodes delineated with a special non-editable stylized heading + vertical 
divider. The nodes it would take body content from would be N visible nodes 
plus or minus the currently selected node. If you move your cursor (up/down 
arrow) past the editable text for one node to the content of the next node 
it will automatically highlight that node in the tree without taking focus 
away from the body. Content from other nodes could be optionally dimmed 
(with shortcutted toggle command) to retain the aspect of focus that Leo 
currently enables by viewing node body content in isolation. 

The benefits/implications of this type of body editor mode:

   - Faster workflow. Switching back and forth between the body is not a 
   big deal but a continuous edit pane would offer a natural method of moving 
   to the next node without leaving the body editor or using shortcuts. Page 
   down/up would always end at the content of the currently selected node 
   without moving to the content of the next node then up/down arrow could be 
   used to move to the content of the previous/next node. 
   - This could provide a flat view of the tree similar to what you see in 
   emacs' org-mode. In essence a type of org-mode emulation, which could help 
   realize a lot features Edward wants to bring from emacs' org-mode. The flat 
   view in general can help give a more global understanding of the code.
   - A mechanism to create a Jupyter like experience where you can create a 
   new "input" node which might be automatically given a node heading "[1] 
   in", type the code you want in the node and and execute it which would 
   create a node directly below the current node with the heading "[1] out" 
   and the output of the previous command and also automatically create a new 
   empty node with the heading "[2] in".
   - Building off the previous example, any type of continuous input/output 
   workflow. I badly want to be able to simulate a shell inside Leo. This type 
   of body editor could facilitate the writing of such "shell" plugins. 
   - A gentler less shocking transition to Leo for new users who are used 
   to "flat" editors. Once they get used to how nodes work.
   - You could use abbreviations or custom commands in the body to create 
   new nodes from the body. Say you type "My next node" by itself on a line in 
   the body and then press the keys for your shortcut to "new-node-from-line" 
   which would create a new node below your current one. The stylized heading 
   shows up in your body editor below the content of the current node. You 
   could then arrow down to switch to the next node, never leaving the body 
   editor but getting the full benefits of a tree structured document.
   - I envision clone-find-all and clone-find-flat becoming even more 
   powerful search tools as you quickly move through the content of the found 
   nodes with just page up/down and arrow up/down.

The generic aspect of such a view mode enables emulating experiences from 
other editors/environments and I believe can be exploited to many other 
user friendly gains 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.

Inventing on principle

[john lunzer]

I was guided to this presentation another presentation by a former 
prominent Scala developer (Paul Phillips).

The presentation by Bret Victor is called, *Inventing on Principle*:

https://www.youtube.com/watch?v=PUv66718DII


I will only preface the video with Paul's quote:

> If you don't come out of that going like, "That guy is talking about some 
> stuff that's... gd" then you're crazy!
>

I'm guess many here have already seen it, but if you haven't watched it in 
a while it's it's worth a second watch. 

-- 
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: Warning: imp.reload hurts super and TDD

['Terry Brown' via leo-editor]

Hmm, I think I'd give this idea a -0  :-)
Working in an environment where you aren't free to install whatever you want, 
because of security concerns, it was very convenient for me to be able to run 
Leo as a side effect of the installation of other software that included both 
Python 2.7 and PyQt.  Only recently has other software which happens to include 
Python 3.x and PyQt come on line.  
But there are a lot of systems when 2.7 is still the core Python, and adding 
"manage multiple Pythons" to the install requirements for Leo adds an 
impediment for new users.  Ubuntu still uses 2.7 at 16.04 (Long Term Support) 
at least, not sure about 16.10 / 17.04, but I wouldn't be surprised if it's 
still 2.7.
At the moment I think "packages I can't use in Leo because they're 2.7 only" 
would outweigh "packages I can't use in Leo because they're 3.x only", although 
I guess that will change.
So, like I said, -0.  I think you points about pointing Leo forwards and saving 
dev. time are really good, and I guess I'm saying I don't have a strong 
opinion... :-}
Cheers -Terry

  From: john lunzer 
 To: leo-editor  
 Sent: Friday, February 10, 2017 12:16 PM
 Subject: Re: Warning: imp.reload hurts super and TDD
   
Edward, doesn't that statement just scream "something is wrong with this" to 
you?
Your time is the most precious resource you have. My advice is to do a freeze 
of Leo (and it's documentation) at version 5.5 or 5.6 as the last Python 2 
compatible version. Make this version available indefinitely. This way people 
can get most of the idea of what Leo is about and if they want to "make the 
jump" they can go from there. This is no different than what Python itself did. 
People got over it eventually. I see people on the forums still using Leo 5.2 
for goodness sake. Leo's history is so rich that Leo 5.5/5.6 will be relevant 
for years. 
One of my favorite Python based tools is xonsh. They made a decision to go with 
Python 3 early and never looked back. Nobody rolls up on the forums/git-issues 
demanding Python 2 compatibility. Anyone who knows enough to want to demand 
Python 2 compatibility knows better than to actually troll a project demanding 
such. 
Additionally, you may be able to migrate to a Python 3 only codebase and still 
support Python 2. Almar Klein, was able to accomplish this with a custom 
translator he wrote a blog post about. 
http://www.almarklein.org/legacy_python.html 
Honestly, give some thought to how much time you will save and how much you can 
simplify the code base by going to a Python 3 only implementation of Python. 
This could be as important a turning point for Leo as any, and would certainly 
align Leo in a completely forward facing direction, which I know is where you'd 
like to take Leo.

On Thursday, February 9, 2017 at 2:29:35 PM UTC-5, Edward K. Ream wrote:
On Thu, Feb 9, 2017 at 9:39 AM, 'Terry Brown' via leo-editor 
 wrote:

Ha, snap - I just ran into the the same issue with VR-4. 

​This is one of the best adverts for Python 3 that I know.  Alas, we are stuck, 
for now, with Python 2.

Funny how nobody complains that pyzo is Python 3 only.

If people only knew how much time I spent futzing with 2/3 issues...

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.


   

-- 
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: Warning: imp.reload hurts super and TDD

[john lunzer]

Edward, doesn't that statement just scream "*something is wrong with this*" 
to you?

Your time is the most precious resource you have. My advice is to do a 
freeze of Leo (and it's documentation) at version 5.5 or 5.6 as the last 
Python 2 compatible version. Make this version available indefinitely. This 
way people can get most of the idea of what Leo is about and if they want 
to "make the jump" they can go from there. This is no different than what 
Python itself did. People got over it eventually. I see people on the 
forums still using Leo 5.2 for goodness sake. Leo's history is so rich that 
Leo 5.5/5.6 will be relevant for years. 

One of my favorite Python based tools is xonsh. They made a decision to go 
with Python 3 early and never looked back. Nobody rolls up on the 
forums/git-issues demanding Python 2 compatibility. Anyone who knows enough 
to want to demand Python 2 compatibility knows better than to actually 
troll a project demanding such. 

Additionally, you may be able to migrate to a Python 3 only codebase and 
still support Python 2. Almar Klein, was able to accomplish this with a 
custom translator he wrote a blog post 
about. http://www.almarklein.org/legacy_python.html 

Honestly, give some thought to how much time you will save and how much you 
can simplify the code base by going to a Python 3 only implementation of 
Python. This could be as important a turning point for Leo as any, and 
would certainly align Leo in a completely forward facing direction, which I 
know is where you'd like to take Leo.

On Thursday, February 9, 2017 at 2:29:35 PM UTC-5, Edward K. Ream wrote:
>
> On Thu, Feb 9, 2017 at 9:39 AM, 'Terry Brown' via leo-editor <
> leo-e...@googlegroups.com > wrote:
>
>> Ha, snap - I just ran into the the same issue with VR-4. 
>>
>
> ​This is one of the best adverts for Python 3 that I know.  Alas, we are 
> stuck, for now, with Python 2.
>
> Funny how nobody complains that pyzo is Python 3 only.
>
> If people only knew how much time I spent futzing with 2/3 issues...
>
> 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: Turning to documentation

[Edward K. Ream]

On Fri, Feb 10, 2017 at 9:37 AM, lewis  wrote:

Just thinking out aloud here as I read about your writing *before* your
> Aha. Is it possible to integrate the concept of chapters as you write your
> executable documents and are 'Composing script lists from a tree of nodes'?
>

​This is not likely to be useful in practice.  Outlines already can
organize demo scripts. That's plenty good enough. Switching chapters would
just slow things down.

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: Turning to documentation

[Edward K. Ream]

On Fri, Feb 10, 2017 at 9:28 AM, Edward K. Ream  wrote:

​> ​
Instant automation!  Do you see how cool this is?

​Although usually simple, ​the various setup/teardown methods help devs
maintain momentum and energy.
​ This is important, especially when confronting a long period of
experimentation.​


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: Turning to documentation

[Edward K. Ream]

​​
​​
On Fri, Feb 10, 2017 at 4:22 AM, Geoff Evans 
wrote:
​
​
​> ​
A good test is both
(a)  an illustration of something the program should do;
(b)  an ability to detect if the program isn't doing it.
In this light, tests appear as helpers toward understanding rather than
obstacles to be overcome.

​Interesting notion.​


​> ​
Why don't more people use Leo (or more of its capabilities)?
​...one part of the answer is that the documentation is hard to use.

Maybe, but there are more plausible reasons. First, millions of programmers
get their start on emacs.  Because their mates use emacs, they can easily
get their questions answered. They can literally look over the friend's
shoulder.

Second, emacs org-mode is good enough (for emacs users). It isn't Leo, but
for at least four years has had powerful scripting capabilities, which in
some ways are Leo's equal or better.

Third, because there are so many emacs and org-mode users, the resources
available to them are immense.  For example, this org-mode tutorial video
, and this longer one
. I haven't watched either
tutorial yet. I will as preparation for developing new Leo videos.

> [Docs should invite, guide, serve as a reference]

All reasonable goals. How do you propose to test 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: Turning to documentation

[lewis]

Just thinking out aloud here as I read about your writing *before* your 
Aha. Is it possible to integrate the concept of chapters as you write your 
executable documents and are 'Composing script lists from a tree of nodes'?
The idea appeals to me and it also possibly reveals how little I know about 
programming. But hey, of course that has nothing to do with aha moments and 
thinking out aloud.

Lewis

On Saturday, February 11, 2017 at 12:18:40 AM UTC+11, Edward K. Ream wrote:
>
> ​​
> On Thu, Feb 9, 2017 at 10:55 AM, Edward K. Ream  > wrote:
>
> ​> ​
> The feeling is that good docs may be akin to small chunks of code
> ​...​
>
> At some point in the last day or so, the phrase *executable docs* popped 
> into my head. Is that phrase itself a breakthrough?  I'm not sure. [No it's 
> not, but it's close].
>
> What *is* clear is that I've never before had so much energy writing 
> docs, or really, writing anything. Clearly, the "less said the better" 
> principle is a key ingredient. And so is intermixing words with example 
> code. It's kinda like using FAQ style for *everything*.
>
> Another thing that is clear to me now.  Composing script lists from a tree 
> of nodes, each node of which can contain multiple demo scripts, is a 
> *huge* breakthrough.  And it's one of the strengths of org-mode.
>
> Clearly, the phrase "executable documentation" perfectly describes the 
> script tree that drives a demonstration.  There is so much energy involved:
>
> 1. It's now dead easy to create and edit nodes.
> 2. Each node naturally describes one slide, or one thought.
> 3. Setup and teardown methods eliminate repetitious code from nodes.
> 4. Testing is instantaneous. Just run the demo.
>
> As I write this, I see that it might be useful to associate names with 
> slides.  That way, we could tell demo.start to start with the slide of a 
> given name.
>

-- 
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: Turning to documentation

[Edward K. Ream]

​​On Fri, Feb 10, 2017 at 7:18 AM, Edward K. Ream 
wrote:

​This post will be pre-writing for a new section in ​demo.md
.


​> ​
My task is now clear.  Create demos that* show Leo in action*!​

This really is a programming task. The example top-level script

in demo.md
 is
no toy.

The *setup *method defines the 'delta' ivar, incremented when changing font
magnification in Leo's body pane. The *teardown* method restores the
original font magnification. The Demo class catches all exceptions, so it
can call teardown in *all* cases.

The *setup_script* method calls demo.delete_widgets(), which frees
individual demo scripts from having to do so. See below for a practical use
for *teardown_script*.

I want to emphasize something.  Demo scripts can use *all *parts of Leo's
API to "run" Leo automatically. For example, this is one way to create a
new node:

p = c.insertHeadline()
p.h = 'a headline'
p.b = 'some body text'

This means that devs don't have to do *anything* "by hand" when creating a
demo.

*Demos are totally reproducible.*
One more cool thing. During development, it's fine to move from one slide
to the next using demo-next (bound to Ctrl-9 in the example top-level
node). Just before creating the video, we can define this *teardown_script*
method:

def teardown_script(self):
self.wait(self.inter_slide_wait)
self.next()

Instant automation!  Do you see how cool this is?

Edward

P. S. > ...it might be useful to associate names with slides.  That way, we
could tell demo.start to start with the slide of a given name.

A silly idea.  @ignore or @ignore-tree allow devs to skip already
"debugged" nodes.

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: Chapter-Select command

[Edward K. Ream]

On Thu, Feb 9, 2017 at 3:43 PM, lewis  wrote:

> It seems the Chapter-Select command is not working. I tested with
>
> @chapter
>Name 1
>Name 2
>
> Cmds> Chapters> Chapter-Select:
> Minibuffer: Select Chapter: Name 1
> reports
> * 'no such @chapter node: Name 1'*
>

​The chapter-select commands works properly. The only valid values are
chapter names:

@chapter name 1
@chapter name 2

The log pane shows the valid values

main
name-1
name-2

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: Turning to documentation

[Edward K. Ream]

​​
On Thu, Feb 9, 2017 at 10:55 AM, Edward K. Ream  wrote:

​> ​
The feeling is that good docs may be akin to small chunks of code
​...​
> I'm pretty sure there is a breakthrough nearby.

Yesterday I started work on "real" slides. In the process, I completed
debugging of demo.py, as explained here
.

Hmm. The rest of this post is pretty much thinking out loud.  You could
call it an Engineering Notebook post. Ignore it if you like, but if you
read on you will be in on the *exact moment* at which an important new Aha
appeared.

Note: I wrote this next paragraph *before* the Aha appeared.

Imo, breakthroughs aren't real unless you can describe *exactly the instant*
the Aha occurred. No, you don't have to remember the time at date at which
it happened, but you have to be able to clearly describe the moment.
Understand?

At some point in the last day or so, the phrase *executable docs* popped
into my head. Is that phrase itself is a breakthrough?  I'm not sure. [No
it's not, but it's close].

What *is* clear is that I've never before had so much energy writing docs,
or really, writing anything. Clearly, the "less said the better" principle
is a key ingredient. And so is intermixing words with example code. It's
kinda like using FAQ style for *everything*.

Another thing that is clear to me now.  Composing script lists from a tree
of nodes, each node of which can contain multiple demo scripts, is a *huge*
breakthrough.  And it's one of the strengths of org-mode.

Clearly, the phrase "executable documentation" perfectly describes the
script tree that drives a demonstration.  There is so much energy involved:

1. It's now dead easy to create and edit nodes.
2. Each node naturally describes one slide, or one thought.
3. Setup and teardown methods eliminate repetitious code from nodes.
4. Testing is instantaneous. Just run the demo.

As I write this, I see that it might be useful to associate names with
slides.  That way, we could tell demo.start to start with the slide of a
given name.

*The big question*

Debugging demo.py has been great fun. And the ideas keep coming, as just
mentioned.

But the big question is the following: *will demo.py help me to create
better tutorials?*

I think the answer is yes, for several reasons.

1. It's *much* easier to create callouts with demo.py than with Camtasia.
As a result, I can create hundreds or thousands of experimental slides to
see what works. Now, I can focus on *what* I want to say, without
production overhead.

2. The new demo.py plugin does not interfere with the rest Leo in *any*
way. This means that demo scripts can automate *all* aspects of Leo's
operation. In this regard, it's unlikely that any subtle bugs exists in the
Demo class. The reason is simple: all the code is dead simple.

3 As a result, I can attempt things in demos that would have been out of
the question previously.  Demos can show how I really work, in real time,
or in "slow motion". I can revise them endlessly until they *work* just
exactly as I want.* And that's the Aha I have been looking for!*

The Aha is this: writing demos is about getting Leo to *work* (as
controlled by the demo script) in a way that *shows* something properly.
The magic word is "works".

In other words, demos don't *tell *about Leo, they *show *how Leo *works*.
There is a debugging process involved, both mental and operational. As a
result demos have exactly the same energy level as writing a program,
because I *am* writing a program.

Ok, now that I see the Aha, there is one more point to make:

4. Improving a video with even a good tool like Camtasia Studio is a
soul-draining endeavor.  It's just way too much work to futz with
post-production details.  In contrast, creating demos with demo.py involves
only *pre-production* work. To revise a video, just revise the demo script,
and re-record.  That's *all*. Notice, there is no real temptation to record
a video at all until everything "just works".

My task is now clear.  Create demos that* show Leo in action*!

Edward

P.S. Last night another thought appeared. It may have had something to do
with the Aha just described.

The thought is that we don't need (or want) fancy arrows in a demo.
Instead, the demo should *itself *be an animation that highlights what we
want to explain. It's close to the Aha, but isn't it.

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: demo.py is ready for use and extension

[Edward K. Ream]

On Thursday, February 9, 2017 at 8:16:18 AM UTC-6, Edward K. Ream wrote:

> Rev cf424c5 completes the demo's docs, demo.md 
, for 
now. This may jiggle a bit, but the big picture will not change.

I spent yesterday developing just a few "real" slides. This helped debug 
demo.py. The documentation in demo.md reflects the latest work.

I am confident that little will change in demo.py:

1. There is a clear separation between the Demo class and the graphics 
classes. The Demo class runs the demo, provides a few helper methods for 
demo scripts, and a *few* utility methods for graphics classes.  That 

*all.2.* Top-level scripts can easily provide new graphics classes by 
overriding graphics classes in demo.py.  For example, a new ShowKey class 
would override Label to highlight a keystroke in a different style and 
location.  Just a few lines of code.

In short, demos won't need more help from the Demo class.

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: Turning to documentation

[Geoff Evans]

This encouraging development prompts me to throw something into the mix 
that's been on my mind for a while.

1.  It starts with Edward's Stupendous Aha about tests from months ago, 
which goes roughly:
A good test is both
  (a)  an illustration of something the program should do;
  (b)  an ability to detect if the program isn't doing it.
In this light, tests appear as helpers toward understanding rather than 
obstacles to be overcome.

2.  Then there's a perennial question: Why don't more people use Leo (or 
more of its capabilities)?  In my mind (and there are those who agree with 
this), one part of the answer is that the documentation is hard to use.

3.  So:  ** What are the tests for documentation? **
Saying that documentation needs tests implies saying that it should *do* 
something, not just *contain* something.  I suggest that at the top level 
what it should do is:
  (a) Invite.  Persuade potential users that Leo offers something they 
want, that their current tools don't supply.  And that they can get at 
least a working version of what they want with a modest investment of 
effort.  Possible subjects for invitations: Leo as a whole; scripts; ILeo 
(how is it better than using %cpaste in a separate IPython window?); vi 
emulation.
  (b) Guide.  (aka Tutorial?)  Given someone who has decided to invest some 
effort, take her through the steps to reach some worthwhile goal.  Perhaps 
best implemented as a set of plateaus, each plateau having a set of 
signposts for choices of where to be guided next.
  (c) Be consulted.  Someone has started to use Leo regularly has a 
detailed question (How do I change the font size?  How do I make python 
indent using 3 spaces instead of 4?) and a generic question:  How do I 
navigate the documentation to answer the detailed question?  For the first 
of my examples, the best I can come up with is "Poke around in leoSettings 
for something that says 'font' and play with changing that in 
myLeoSettings"; for the second example, "I have no idea".

Of course, if I knew Leo better I could have said more sensible things 
here.  Chicken and egg.

Cheers,   geoff

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