On Sat, Sep 24, 2011 at 3:12 PM, ne1uno <[email protected]> wrote:
> wouldn't it be great to have a first class c importer?
Importing C "perfectly" would require AI. Furthermore, people may
have legitimate preferences for various ways of doing the import. For
instance, Kent prefers to split nodes whenever possible: I like, (or
liked) fewer nodes.
It may be that the simplest, most flexible, approach would be to
define tools (scripts, @button nodes) that adjust the result of
imports. For example, here is an @button node I created recently:
@button join-below
'''Join p.b to p.next().b. and delete node p.'''
u = c.undoer
p2 = p.next()
if p2:
b = p.b.lstrip()
if not b.endswith('\n'):
b = b + '\n'
p2.b = b + p2.b
p.doDelete(p2)
c.redraw(p2)
This merges the body text of the selected node with the body text of
the next node, then deletes the first node. This simple script helps
a lot, even without the obvious additions: making it undoable and
joining only the selected text.
> hiding the complexity of platform & compiler/option #defines.
Possible, but it is tricky to generate the proper code (tree).
> invisible (TM) nodes would be fruitful here.
Hmm.
> switched on by @#define.
> with an @#define= collection node or using a bunch of headlines.
> and an rclick flipper for true/false, defined/not defined
> declarations.
I don't see the need for something this fancy.
> we know c isn't disappearing. quite a few people still regard
> any so called scripting language as a nuisance.
> maybe ok for prototyping but not for the final product.
Interesting point of view: I'm amazed when I see programs like SIP
written in C. I suppose it is just inertia: change is going to
create extra work, no matter how much easier to maintain the result
would be.
> meanwhile I wait for the inspiration or someone else to nail down
> a regular expression c language parser.
A regex parser would either be impossible, or just impossible to understand :-)
Actually, C is fairly easy to parse: Outer expressions contain a
head, zero to two parenthesized parts, then either '=', '{' or ';'.
The first is an object (struct/union/typdef) initializer, the second
is a function definition, and the third is a function declaration if
there are one or two parenthesized parts, otherwise it is a variable
declaration.
In any event, parsing is really not the problem: Leo's C importer does
pretty well, and any improvements would come from better recognition
of higher-level patterns, not recognition of lower-level C (and CPP)
constructs.
> Maybe a tokenizer is enough.
A C tokenizer is almost identical to a Python tokenizer: different
keywords and operators, but otherwise very simple. Alas, tokenizing
really does not solve the difficult problems, namely the recognition
of higher-level patterns.
> I did run c code through AStyle then through your old c2py via
> buttons.
> for code that would remain in c,
> in SciTE through google CPPlint program to point up flaws,
> and to get the context sensitive help from various CHM.
Any and all bug reports against Leo's C importer are welcome.
> [flawfinder and splint]
There are not likely to be too helpful. The fundamental constraint is
round-tripping: writing imported files produces the original input
file, except for unimportant whitespace.
> we have had a few plugins/buttons/attempts at designing an
> interface to get a program node compiled. this is also a decent
> way to get info on the quality of code by turning all warnings on.
> fails for snippits. never quite simple to hookup or modify painless.
Yes. A fertile field for invention.
> perhaps the biggest problem is knowing what is available and where.
I agree. There are many possible approaches: documentation, buttons,
toolbars, apropos-whatever. This is a symptom of a problem, not
evidence that the problem has been solved.
I am going to reply to the rest of this important post later. It has
stopped raining in Petoskey Michigan, so it's time for a walk.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
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.
