What I've been doing lately

[Edward K. Ream]

There has been a lot of activity that will benefit Leo fairly directly:

1.  https://groups.google.com/forum/?fromgroups#!forum/python-static-type-checking has been discussing the TypeScript (ts) language: http://www.typescriptlang.org/

This is very cool, and it demonstrates fast, incremental, dynamic type checking for JavaScript (js).  All the techniques in the (open source) ts tools will apply even more easily to Python.  True, there are behind-the-scenes databases of type info that are required, but the same kind of thing can be done for Python.

The ts tools demonstrate that it is possible to create an *accurate*, static, design-time (edit-time) model of the dynamic js types(!)  The model allows a programmer to express their intentions.  These intentions guide code completion, but they can not be completely checked at run time. This should hardly be a surprise.  Nevertheless, I believe that the design point of ts is reasonable, and furthermore, I have wanted such tools all my life.

I plan to study the ts sources in detail.  As the first step, I have created a ts importer.  Perhaps even more importantly, I have substantially improved the "recursive import" script in scripts.leo.  Look for the node, "Recursive import script (with cleanups)".

The script is quite good now, but I think it is time to turn this script into a Leo command.  To do this, the script will look in some node for arguments, say either the presently selected node, c.p, or the nearest "special" node, say the nearest @recursive-import node.  The idea would be to have the body text contain something like this::

   path = r'C:\Python26\Lib\site-packages\rope',
   theTypes' = ('.py','.ts',)
   safe_at_file = True

The idea is that the recursive-import *command* would look for this node, execute its body text to discover params, and then proceed.  This is a new pattern for Leo command: it will be *much* faster than entering options in the minibuffer, and it will allow for a common code base in the command, rather than having various copies of the recursive import script in various .leo files.

Finally, planned work on the Python static type checking project will improve the leoInspect module.

2. I have been working on one of my brother Speed's projects.  It's clever: it translates Leo outlines into html in such a way as to eliminate the tedium of writing html tags.  For example, consider a Leo outline whose headlines are::

    -doctype
    - html
        - head
            - +contents
        - body
        (etc.)

Using Speed's code, this will automatically generate all the html tags for you.  It's an interesting alternative to the Leo2Html plugin that already exists.  We'll be announcing the project when it closer to completion.  The fundamentals are already in place, with complete unit tests.

To summarize, I've been working on several projects that will benefit Leo in the long run.  Take a look at the TypeScript demo: we have to have something similar for Leo and Python.

Edward