>
>
> Vitalije, are you thinking of a strict or lenient parser?
>
> EKR
>
I must say that I thought that the writing full lexer/parser for the jungle 
of current javascript dialects was out of question. It seemed to me way too 
much work for just a single language. That is why I did abandon this 
approach and proposed some kind of combination of human intelligence and 
dummy but fast computer text operations, so that user can very easily shape 
code the way he/she likes.

When rust language appeared on this forum, I've got interested in it 
especially when I learned that it is quite easy to make python extensions 
in rust. Rust also allows pattern matching which is wonderful feature for 
writing parsers. There is a rust library that parses modern javascript. 
When I saw all these, I had an impulse to try it for Leo import when I got 
some time to experiment with this.

There is also python module ply <https://github.com/dabeaz/ply> for writing 
lexer/parser functions in pure python. AFAR this module was requiring 
latest Python3.6, but as I write this and check the previous link, it seems 
that they made ply compatible with both python2 and python3 versions (which 
is good news for Leo if this module is to be used).
I can try to:

   - write lexer/parser using ply in pure python
   - write python extension for using rust library for creating 
   lexers/parsers

Any of this will build AST of imported script. With AST at ones disposal, 
one can easily check all function definitions, object definitions, property 
definitions for their start line and end line. In case they contain more 
lines than some user preference this peace of code can be extracted into 
separate node, inserting @others if it is not already inserted. Also types 
of AST nodes can give very good suggestion for what the headline might be.

Javascript is important language nowadays and it might be worth building 
lexer/parser for it. But it is open-ended project. Javascript syntax is 
permanently changing and even native javascript tools have a hard time to 
keep up.

On the other hand for the effective use of AST we still would need those 
text manipulating functions. It seems to me that these functions should be 
our first target, and then if they would not suffice, build lexer/parser 
that would generate AST  which can be used to automatically split the 
source file into nodes.

Importers are extremely important for using Leo like an ordinary text 
editor. Suppose some user wants to try Leo and issues command leo 
somesource.js Leo would respond by opening new empty outline and importing 
the given source file. If it takes too much time (more than 500ms) it would 
make very poor impression on the user. In case the user is forgiving and 
willing to wait that long, at least what he/she sees after waiting must 
look good enough. Otherwise, most of the users would regret for even trying 
Leo.

Vitalije

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

Reply via email to