>>> Joakim Verona <joakim@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
[ ... ]
>>>class WXDLLIMPEXP_XRC wxPanelXmlHandler : public wxXmlResourceHandler
>>> virtual wxObject *DoCreateResource();
>>> virtual bool CanHandle(wxXmlNode *node);
>>>are there any obvious reasons why this shouldnt be parsed?
>> The C parser needs a means for stripping unusual macros at the
>> lexical level. The parser doesn't know what your keyword is.
>Ok, that is kind of obvious now that you say it.
>But shouldnt the iterative style parser be able to discard these
>macros? Would it be possible to subclass wisent parser somehow, so
>that these macros can be explicitly added for the wxwidgets package?
The iterative parser can eliminate junk between declarations. This
keyword is between the "class" keyword and the name, so it would need
to be added to the parser for one class.
The iterative parser would see "class WXDLLblah", and give up on
"class", then look at "WXDLLblah wxPanelXmlHandler", and give up, etc
etc until the whole declaration is missing.
You can use `global-semantic-show-unmatched-syntax-mode' to look at
what the parser can and cannot understand.
I would like to add macro expansion to the lexical analyzer someday,
but that is not in the cards.
Also, the C parser uses the old bovine parser generator at the moment.
>Or would some aproach reading .o or .pch files be more fruitful?
If there is an application that dumps symbol contents from those,
then it might be possible.
[ ... ]
>> I had not yet fully commented it. Try it out, and add more comments
>> to the original as you discover things that are unclear. That will
>> be the best test of its usefulness. I was fiddling with a separate
>> copy for use as an ebrowse back-end.
>> Developer updates can take up to an hour to synchronize with the
>> anonymous CVS server so semanticdb-skel.el may not appear right away.
>> I am hoping to release the official 1.0 version soon. That should
>> make getting the changes above easier.
>Nice! I read your PRERELEASE_CHECKLIST file, and I can offer to
>perform the tests for CVS emacs on fedora core 2 if thats any help at
>all. If I can compile cvs emacs using mingw for windoze, I can offer
>that as well. (My msvc build of cvs emacs wasnt any good.)
[ ... ]
I hadn't gotten around to double-checking or announcing that file yet,
but indeed, I will probably upload "cedet1.0pre1.tar.gz", post to this
list (cedet-devel), and ask people to try out the checklist.
(Something that Klaus had suggested.)
If all goes well, 1.0pre1 will roll directly into 1.0 and we will be
done (for now).
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org