On Sep 26, 3:38 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Sat, Sep 24, 2011 at 3:12 PM, ne1uno <eltro...@gmail.com> 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.
>
[...]
>
> 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.
[]
>
> Any and all bug reports against Leo's C importer are welcome.
>
yea, on second thought, I was really thinking more of the other
language importers. like html. that basically create a flat file
needing additional manual labor.
http://clang.llvm.org/
I had bookmarked this but forgot to look it up.
should be easy to get it working if you can stomach the toolchain.
uses cmake & msvc to build and python to test.
I gather, clang/llvm is a drop in replacement for gcc. intermediate
file is a c ast. most of the hard work done.
I will probably have to wait for the binaries or a larger primary
drive. the website lists many in process and llvm in use
projects that sound very interesting for code analysis.
most recently, qtcreator added clang support.
that would be the one to beat since nearly the first version.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
