Re: imenu parsing of ObjC classes and selectors

Alan Mackenzie <[email protected]> writes:

> Thanks for taking the trouble to report this bug, and thanks even more
> for such a useful test file.

> This bug is an unexpected consequence of the change of ~1 year ago, such
> that the character @ is now categorized as an identifier component (in
> Emacs jargon, its "syntax" was changed).
>
> So lines like:
>
>     @end        // NSFont (Emacs)
>
> were getting parsed as a C function with "@end" as the type and "NSFont"
> as the name.  This parser has to be fast, so is not very intelligent.
> Basically it's just a regexp search.

> The following patch, I hope, fixes it.  It should apply cleanly to the
> version of CC Mode contained within the Emacs master branch (and also
> the Emacs release branch).  Would you try it out, please, on your real
> Objective-C source, and let me know how well it works.  Note that some
> Emacs variables' values have been changed, so it would be best to
> restart Emacs after rebuilding CC Mode to ensure the obsolete values
> don't remain.

Thanks for looking into it, Alan.  I was able to apply and test your
patch.  Once I re-evaluated the updated variables and recompiled
cc-menus.el, it is now working very well in my testing.  This will be
very nice to have, as there are some very long implementations in the
giant emacs-mac files I'm working on... easy to get lost.

BTW, I recently started using breadcrumb-mode, which pulls data
exclusively from imenu as point moves (unlike which-func), and is hence
a very nice way to quickly validate the imenu listing for content and
positioning.

I assume these changes will land on master.  I'll be sticking with v31
release for the next year or so.  Aside from upstream, do you release
new versions of cc-mode on ELPA or any other package repository?

Thanks again for your work maintaining such a widely capable set of
modes!

JD