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
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/DArt4gu6vPcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
