As of rev ae40ad3 the new javascript importer seems ready for prime time.
*Notes*
1. The importer now uses the first non-blank line of each block as its
headline. This is more general, and typically more useful, than trying to
guess what the headline "should be". No more regex patterns.
2. The code seems rock solid. The perfect-import check allows the import
code the "clean" blank lines, but that's all. There hasn't been any
perfect-import problems for some time. Because of the line-by-line nature
of the scanner, the *only *possible failures would be whole lines inserted,
deleted or moved. That's unlikely in the present code base.
3. The importer will likely do something reasonable with *any* kind of
javascript file, no matter how horribly formatted. That does not mean,
however, that the resulting outline will be Leonine. Lines like,
) {
which is present in main.js, (part of the Jupyter project), result in code
that can't be represented naturally in Leo. But if you are willing (and
permitted) to insert newlines, the workaround is simple. Just convert it
to:
)
{
That way Leo can:
a) *end *the block starting with "(" properly, and
b) create another block for the block starting with "{".
So it's possible to turn fairly horrible javascript into a Leonine
outline. Try it!
4. Leo inserts properly indented @others directives to preserve leading
whitespace *exactly.* But if you are willing (and permitted) to change
leading whitespace, Leo can clean up your code. Just look for blocks
containing something like:
{
@others
}
And change it to:
{
@others
}
Then you can go about regularizing the leading whitespace in the child
nodes. It's easy.
5. The present code generates only @others. The importer can (and has)
generated outlines using section references. Alas, Leo's @auto write code
does not permit section references in @auto trees.
I'm not entirely sure why the restriction is in place. It's truly
annoying. I'm considering a user option that would allow @auto to *write*
section references. That way importers could *generate* section references.
The simplification is significant for javascript. Section references allow
the importer to create child nodes only for real blocks. When the importer
is limited to @others, it must create children for plain text that occurs
between blocks. That can greatly increase the number of child nodes, to no
real purpose.
*Summary*
The present javascript importer is already miles ahead of the old code.
It's good enough as it is.
I shall experiment with allowing the javascript importer (and maybe
others?) to generate section references. This will involve siginificant
changes to Leo's core and the perfect-import logic. Happily, there are
lots of unit tests. If this work is successful, jss.rescan_block can
generate section references just by calling jss.make_ref_children instead
of jss.make_at_others_children. The code has already been tested.
Aside from this switcheroo, I plan no further work on importer itself.
Edward
P.S. The present javascript importer is almost completely self-contained.
It interfaces with Leo's core via the jss.scan and jss.check methods only.
In fact, very little is going on behind the scenes, aside from the complex
logic that associates jss.scan with javascript files. Aside from this
"glue", the JavaScriptScanner class contains *all* the relevant code. (The
code uses a few very simple utilities in the base scanner class.)
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
