Re: CEDET update

[Eric M. Ludlam]

On Wed, 2009-09-23 at 12:20 +0200, David Kastrup wrote:
> Juri Linkov <address@hidden> writes:
> 
> >>   > 2. I would like to make it possible to enable the different parts of
> >>   >    CEDET using the menu-bar.  However, CEDET offers too many knobs to
> >>   >    fit in any of our existing menus, so it probably needs its own
> >>   >    top-level menu.  One possibility is to add a "toggle CEDET" menu 
> >> item
> >>   >    to the Tools menu, which adds or removes a "CEDET" top-level menu.
> >>   >    But this is not "standard menu-bar behavior"-ish.  Thoughts?
> >>
> >> If you do this, please use a more generic name rather than "toggle
> >> CEDET", that means nothing for most users...
> >
> > "Enable IDE"?
> 
> Emacs _is_ an IDE.
> 
> Maybe "IDE mode".  I don't know which major modes are affected by this;
> it may make sense to offer this just in CC modes depending on that.
> 

I would guess it depends on how CEDET is "integrated" into Emacs.  If
CEDET is like GNUs, then users would need something like "Enable Project
features (CEDET)", similar to "Read Net News (Gnus)".

If the pieces of CEDET should be infrastructure (which is how I tried to
build it), then it is a mish-mash of features.  EDE enables detection of
"projects", and a "Project" menu.  I did my best to make "EDE Global
mode" be transparent when not in a project.  Perhaps there are some
tweaks that could be done so it could be on-by-default/out of the way in
the same way that auto-mode-alist is automatic?

The Semantic pieces are different since there is more of a hit when you
enable parsing of files in idle time, but setting up parsing tables for
major modes is also transparent, and has no affect, other than loading
misc Semantic files.  Perhaps there are tweaks that could be done to
allow that also?  I would imagine over time major-modes would set these
variables up on their own, instead of having Semantic specific features,
so the effect would be the same.

Then there are the things Semantic can make better, such as imenu,
which-func, eldoc (via a different mode), hippie-expand, and commands
like "beginning-of-defun".  That is more of a toggle, since users would
want to choose the old vs new implementation.  This is not really "IDE",
those are just aspects of an IDE.  This goes back to the question of ...
should the buffer parsing mechanisms be considered infrastructure, and
have them all there for general use.  In a lot of ways, having access to
the parsing information is a lot like being able to call 'forward-sexp'.
There is a pile of useful data just waiting to be used to do cool stuff
in a buffer.

I think it is way too early to try and call this infrastructure, but it
could be described as "Enable Experimental Buffer Analysis" or "New Code
Parsing Features" for a release or two while people figure out where it
really belongs.  Major modes could choose to use Semantic parsing
information even if the user doesn't turn on the maintenance
infrastructure, the effects will just be local to a single buffer.

Eric

Eric