Leo + Python: the ultimate scripting tool: Conclusion

[Edward K. Ream]

> Thanx so much for your thought-provoking, stimulating and clarifying
ideas/comments.

You are welcome.  This is an exciting time for me.

> Say, in a model building environment, first you dream about some fuzzy
things...

I'm glad you mentioned this.  It's so important to be able to explore
_easily_ while still being confused about what it is one is trying to do.
On Leo's SF Forum I described how I ended up creating the script-find and
script-change commands.  I'll repeat it here, because it illustrates
something crucial about executing Python scripts in Leo.

[quote]
As late as yesterday I wasn't sure how this would work, or if these new
options were even necessary.  Here is a summary of what I did yesterday.

1.  As usual, just being able to begin this project was very important.  It
turned out that the ability to execute test scripts rapidly without leaving
Leo was crucial.  I was able to run through many ideas quickly so that no
intellectual momentum got wasted.

2.  I was quite confused about what was needed. After all, there are already
a lot of find/change scripts in scripts/leoFindScript.py.  But these scripts
are not interactive. I wanted to see if I could write an interactive find
script without using Leo's Find panel.  If I could, I might simplify the
entire process: no changes required to Leo's find/change code.

I soon discovered, however, exactly why Leo's Find panel is necessary.  The
problem is that interactive scripts need a _nonmodal_ dialog always present
so that the user can choose "yes", "no" or "cancel".  However, interacting
with that non-modal dialog would be quite a problem for the script.  Rather
than reinventing the wheel, it is _so_ much easier just to use the Find
panel that already exists.  And of course, it makes sense to do this.

3. So ok, we do, in fact, need Script Search and Script Change options in
Leo's Find panel.  The next big big question was: how to do this?  Always
present in my awareness was the fact the present find/change code is
complex.  A few experiments with hacking into this code made me leery of
messing with this code.  For one thing, the code is all Tk based.

4. I messed around with some more test scripts.  Don't remember how it
happened, but finally a huge Aha happened:  the Find/Change scripts in the
Find panel don't need any help at all from Leo!  They can essentially do
everything on their own!  Here is how I entered this Aha in my diary:

- Leo doesn't clear app.searchDict.  However, a _script_ can a) init itself
and b) bring up the find window (Eureka!)

- The find script is responsible for traversing the tree.

- The find script is responsible for highlighting the found text or
otherwise indicating to the change script what the found text was.  For
example, the re find script can set app.searchDict["m"] to the match object.

- The find script must communicate with the change script.  Leo does
nothing.

- The change script must change the text, usually by using
v.setBodyStringOrPane.

BTW, the first Eureka seems almost irrelevant now, but somehow it was really
important at the time.  Anyway, you can see that these notes clearly
indicate that Leo need not get intimately involved in "managing" the
search/change scripts.  This basic principle is the real Aha, and it made
the rest of the work routine.

5. With this clear vision in mind, it became routine to add support for
find/change scripts.  What I did:

a) Added support for new c.pattern_match_flag and c.pattern_search_flag
ivars.  There was a digression until a fixed a config bug that was blocking
initing of these ivars.

b) Changed the top-level find/change code so that it simply calls code to
execute the scripts in the find/change text area if the corresponding ivars
were set.

That's all!!
[end quote]

The point is this: I did _not_ have a clear picture of how script-find and
script-change would work when I started, and moreover what picture I had was
confused and wrong.  Yet somehow it was easy to noodle around until the
creative unconscious created an initial Aha.  After that, it was smooth
sailing.

> Biology and bioinformatics (among many other domains) might gain a lot
using the Leo/Python great combo.

I've thought so too.  One thing I didn't mention in my "seven reasons" is
that Leo's outlines are isomorphic to dags (directed acyclic graphs).  Dags
are much _more_ powerful than completely general graphs.  Indeed, the
transitive closure of a general graph is just the entire graph again, so
Leo's clones would not be possible (would not be well-defined) in a general
graph.

Edward
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------