CEDET update

CEDET update

[Chong Yidong]

The `cedet-branch' branch now contains all the major components of
CEDET: EIEIO, the Semantic parser, Srecode, and EDE.  The latter two are
not tested extensively yet.

If you have not taken a look at this branch, now would be a good time,
as I plan to migrate this code to the trunk soonish.  As most of the
code is now in place, please feel free to suggest patches and changes to
that branch.

Here are some remaining problems on which opinions are welcome:

1. How to activate CEDET?  In the upstream code, just loading the CEDET
   libraries changes your Emacs environment, e.g. it adds mode hooks
   that start the Semantic parser whenever you visit a parser-supported
   file.  A built-in Emacs package cannot behave like this, so in this
   part of the code we must diverge from upstream.

   I have added a minor mode called semantic-mode to deal with this
   problem for Semantic (which is the main offender).  All the Semantic
   parser mode hooks are moved from top-level into this minor mode.

   This minor mode also toggles some of the minor modes that come with
   Semantic.  The affected modes are in the `semantic-default-submodes'
   variable.  So customizing this variable takes the place of the
   hairy methods (involving names like semantic-load-turn-everything-on,
   semantic-load-enable-code-helpers, etc.) used upstream, which again
   are not suitable for a built-in package.

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?

3. Semantic contains a package called Senator, which modifies many of
   the standard Emacs commands to use the parser information.  For the
   built-in version of Semantic, we should probably fold some of this
   functionality into the rest of Emacs.  As an example, I made a change
   to the `complete-symbol' function (bindings.el) so that if Semantic
   is running, it will call semantic-complete-symbol (a modified version
   of senator-complete-symbol that uses standard completion functions).
   I think `find-tag' can be dealt with similarly.  The question is,
   what do we do with Senator ?  Should we keep a compatibility package,
   drop it, or what?  Again, opinions welcome.

CEDET update

[Nick Roberts]

 > The `cedet-branch' branch now contains all the major components of
 > CEDET: EIEIO, the Semantic parser, Srecode, and EDE.  The latter two are
 > not tested extensively yet.

Does it include ECB?  I would like to use tree-buffer.el for watch expressions
in the GDB Graphical Interface instead of the speedbar.  If not, does CEDET
have something similar?  Otherwise, could we add that to the trunk too?  ISTR
that, at one time, there was talk about including ECB in Emacs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: CEDET update

[Chong Yidong]

nickrob@snap.net.nz (Nick Roberts) writes:

> Does it include ECB?  I would like to use tree-buffer.el for watch
> expressions in the GDB Graphical Interface instead of the speedbar.
> If not, does CEDET have something similar?  Otherwise, could we add
> that to the trunk too?  ISTR that, at one time, there was talk about
> including ECB in Emacs.

No, ECB is not included.  My feeling is that including it right now will
lead to "indigestion"; CEDET is already a big enough addition.  (Adding
ECB would also require us to get the window grouping interface working.)

That reminds me: I haven't replaced "our" Speedbar with CEDET's version.
I'm not sure how to begin going about doing that.  Eric?

Re: CEDET update

[Nick Roberts]

 > > Does it include ECB?  I would like to use tree-buffer.el for watch
 > > expressions in the GDB Graphical Interface instead of the speedbar.
 > > If not, does CEDET have something similar?  Otherwise, could we add
 > > that to the trunk too?  ISTR that, at one time, there was talk about
 > > including ECB in Emacs.
 > 
 > No, ECB is not included.  My feeling is that including it right now will
 > lead to "indigestion"; CEDET is already a big enough addition.  (Adding
 > ECB would also require us to get the window grouping interface working.)

You've not answered my question: does CEDET have something similar?

 > That reminds me: I haven't replaced "our" Speedbar with CEDET's version.

Which might make it more important for the GDB Graphical Interface not to
use the speedbar.

The file tree-buffer.el is 168k and appears to be self contained. CEDET seems
to be fifty times bigger.  As for causing "indigestion", it brings
Mr. Creosote to mind:

"Just one more wafer-thin mint, sir?"

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: CEDET update

[Chong Yidong]

nickrob@snap.net.nz (Nick Roberts) writes:

> You've not answered my question: does CEDET have something similar?

I don't know; I've never used tree-buffer.  Maybe Eric can shed light.

Re: CEDET update

[Eric M. Ludlam]

On Mon, 2009-09-21 at 22:53 -0400, Chong Yidong wrote:
> nickrob@snap.net.nz (Nick Roberts) writes:
> 
> > Does it include ECB?  I would like to use tree-buffer.el for watch
> > expressions in the GDB Graphical Interface instead of the speedbar.
> > If not, does CEDET have something similar?  Otherwise, could we add
> > that to the trunk too?  ISTR that, at one time, there was talk about
> > including ECB in Emacs.
> 
> No, ECB is not included.  My feeling is that including it right now will
> lead to "indigestion"; CEDET is already a big enough addition.  (Adding
> ECB would also require us to get the window grouping interface working.)
> 
> That reminds me: I haven't replaced "our" Speedbar with CEDET's version.
> I'm not sure how to begin going about doing that.  Eric?

Please do not merge the CEDET speedbar into the Emacs one.

The Emacs one has moved forward, and the CEDET one is special only
because it is full of Emacs version and flavor compatibility code going
back to Emacs 19.34 or there-about.

Thanks
Eric

Re: CEDET update

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> 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...

Re: CEDET update

[Juri Linkov]

>   > 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"?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: CEDET update

[David Kastrup]

Juri Linkov <juri@jurta.org> 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.

-- 
David Kastrup

AW: CEDET update

[Berndl, Klaus]

Hi,

i'm the maintainer of ECB and therefore also for tree-buffer.el... as the naming already expresses, tree-buffer.el is independent from ECB (the name doesn' start with ecb-) though it has been developed primarly for ECB - but is contains NO dependency to ECB and AFAIK ;-) and also no advices - it simply is a library which allows displaying arbitrary stuff in a tree-structure... is can display the tree completey in ascii-manner (e.g. [+] for an expand-symbol) but it is much nicer when using images for this...

Well, back to topic: It you like it you can integrate tree-buffer.el into Emacs as stand-alone lib... (when images should be used you can also integrate the images of ECB)...

But, i still have not signed any papers - but if you tell me what i have to do, where i can get them etc.. , then i can do it...

best regards
klaus

________________________________________
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] im Auftrag von Nick Roberts [nickrob@snap.net.nz]
Gesendet: Dienstag, 22. September 2009 05:13
An: Chong Yidong
Cc: Eric M. Ludlam; emacs-devel@gnu.org
Betreff: Re: CEDET update

 > > Does it include ECB?  I would like to use tree-buffer.el for watch
 > > expressions in the GDB Graphical Interface instead of the speedbar.
 > > If not, does CEDET have something similar?  Otherwise, could we add
 > > that to the trunk too?  ISTR that, at one time, there was talk about
 > > including ECB in Emacs.
 >
 > No, ECB is not included.  My feeling is that including it right now will
 > lead to "indigestion"; CEDET is already a big enough addition.  (Adding
 > ECB would also require us to get the window grouping interface working.)

You've not answered my question: does CEDET have something similar?

 > That reminds me: I haven't replaced "our" Speedbar with CEDET's version.

Which might make it more important for the GDB Graphical Interface not to
use the speedbar.

The file tree-buffer.el is 168k and appears to be self contained. CEDET seems
to be fifty times bigger.  As for causing "indigestion", it brings
Mr. Creosote to mind:

"Just one more wafer-thin mint, sir?"

--
Nick                                           http://users.snap.net.nz/~nickrob

AW: CEDET update

[Nick Roberts]

 > Well, back to topic: It you like it you can integrate tree-buffer.el into
 > Emacs as stand-alone lib... (when images should be used you can also
 > integrate the images of ECB)...

I would like to see all this in Emacs.  It must still be much smaller than CEDET.

 > But, i still have not signed any papers - but if you tell me what i have to
 > do, where i can get them etc.. , then i can do it...

I think you just need to contact the copyright clerk (Donald Robertson?) at
assign@gnu.org and ask for assignment  papers for Emacs but it also needs the
agreement of the maintainers, Stefan and Cyd, that it should be included in
Emacs.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

Re: CEDET update

[Eric M. Ludlam]

On Wed, 2009-09-23 at 12:20 +0200, David Kastrup wrote:
> Juri Linkov <juri@jurta.org> 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

Re: AW: CEDET update

[Chong Yidong]

> But, i still have not signed any papers - but if you tell me what i
> have to do, where i can get them etc.. , then i can do it...

I'll send you the information by private email.

tree-buffer.el [was Re: AW: CEDET update]

[Glenn Morris]

Chong Yidong wrote:

>> But, i still have not signed any papers - but if you tell me what i
>> have to do, where i can get them etc.. , then i can do it...
>
> I'll send you the information by private email.

There are other authors:

http://ecb.cvs.sourceforge.net/viewvc/ecb/ecb/tree-buffer.el?view=markup

Jesper Nordenberg <mayhem at home.se>
Kevin A. Burton

The latter already has a general Emacs assignment, but presumably
needs to agree to contribute tree-buffer.

AW: tree-buffer.el [was Re: AW: CEDET update]

[Berndl, Klaus]

I will contact Jesper ... 

-----Ursprüngliche Nachricht-----
Von: Glenn Morris [mailto:rgm@gnu.org] 
Gesendet: Donnerstag, 24. September 2009 05:29
An: Chong Yidong
Cc: Berndl, Klaus; Nick Roberts; emacs-devel@gnu.org; Eric M. Ludlam
Betreff: tree-buffer.el [was Re: AW: CEDET update]

Chong Yidong wrote:

>> But, i still have not signed any papers - but if you tell me what i
>> have to do, where i can get them etc.. , then i can do it...
>
> I'll send you the information by private email.

There are other authors:

http://ecb.cvs.sourceforge.net/viewvc/ecb/ecb/tree-buffer.el?view=markup

Jesper Nordenberg <mayhem at home.se>
Kevin A. Burton

The latter already has a general Emacs assignment, but presumably
needs to agree to contribute tree-buffer.