2012-11-21 AM12:14 <cedet-devel-request@lists.sourceforge.net
Send Cedet-devel mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cedet-devel digest..."

Today's Topics:

   1. Java and static/instance context (Vladimir Kazanov)
   2. Re: semanticdb db-mk.el wrong path? (David Engster)
   3. Re: Setting up to browse madwifi (David Engster)
   4. Re: Cedet from bzr and Emacs (Charles Philip Chan)
   5. Re: Cedet from bzr and Emacs (David Engster)
   6. Re: Disappearing buffers (Damien DEVILLE)
   7. [PATCH] contrib: small fix for cedet-contrib-load (Miguel Guedes)
   8. Re: EDE projects for JVM-related languages & build        tools
      (Alex Ott)


Message: 1
Date: Thu, 15 Nov 2012 02:49:02 +0700
From: Vladimir Kazanov <vkazanov@inbox.ru>
Subject: [CEDET-devel] Java and static/instance context
To: Cedet-devel@lists.sourceforge.net
Content-Type: text/plain; charset="utf-8"

Hi, everyone!

While fixing bugs I noticed that Cedet (for Java) does not separate
static/instance contexts. In static functions and blocks only tags with the
"static" typemodifier should be accessible, and both static and usual
methods/vars/classes in an instance context.

I thinking about implementing this particular feature, and this should not
be too hard, as all the info required is already available in tags received
upon completion. I've spent an hour or two trying to find a canonical way
to implement this, but failed. Which is confusing! In three languages Cedet
claims to support there is such a concept.

Maybe I missed something? Or overloading
semantic-analyze-possible-completions-default function with a java-specific
one is the only way..? Or even extending a default function would be

Yours sincerely,

Vladimir Kazanov,
software developer,
mob. +7 (963) 304-05-12
ICQ: 82042707
skype: stvovka
email: vkazanov@inbox.ru

? ?????????,

???????? ???????,
???. +7 (963) 304-05-12
ICQ 82042707
skype: stvovka
??.????? vkazanov@inbox.ru
-------------- next part --------------
An HTML attachment was scrubbed...


Message: 2
Date: Wed, 14 Nov 2012 21:51:11 +0100
From: David Engster <deng@randomsample.de>
Subject: Re: [CEDET-devel] semanticdb db-mk.el wrong path?
To: Zhenchao Li <cockneykevin@gmail.com>
Cc: cedet-devel@lists.sourceforge.net
Message-ID: <871ufvsybk.fsf@randomsample.de>
Content-Type: text/plain; charset=iso-8859-1

David Engster writes:
> Zhenchao Li writes:
>> ? ? I checked out cedet recent version and tried to use the?semanticdb.sh to
>> build cache for a set of c++ files. However there seems to be some erros due to
>> change of cedet directory structure.
> Yes, semanticdb.sh wasn't properly upgraded to reflect the new
> structure.

I think it should be fixed now.



Message: 3
Date: Thu, 15 Nov 2012 20:28:43 +0100
From: David Engster <deng@randomsample.de>
Subject: Re: [CEDET-devel] Setting up to browse madwifi
To: Maindoor <sanjeevfiles@yahoo.com>
Cc: "cedet-devel@lists.sourceforge.net"
Message-ID: <87wqxmr7h0.fsf@randomsample.de>
Content-Type: text/plain

Maindoor writes:
> 1) With the last open brace commented, I get symbol references
> (semantic-symref-symbol of nt_node only from the current directory (ie. net80211
> when searched from ieee80211_node.c). there are some references in ath directory that are not shown.
> 2) When the last brace is corrected. ie matched properly then I get "No references
> found". when I do the semantic-symref-symbol of nt_node from a ".h" file I get
> "Cannot analyze buffers not supported by semantic".

If you don't have defined a project (which is the case in 1)),
semantic-symref will not find your GNU global index and simply use
'grep' to find symbols. But since it has no project, it will only search
the current directory.

If you have a proper project, it will use GNU global, but global doesn't
know C++ very well. It does not index class members, for instance, which
is why it says it cannot find references. Just do "global -c" in the
root of your project to see the symbols it has in its index. The error
you're getting in the ".h" file is probably a bug.

It might be that another indexing tool like 'idutils' could work better
because it actually is *less* smart than global, but I'm not sure if
it's worth fiddling with this stuff. I usually just use M-x rgrep in
cases like these.



Message: 4
Date: Sat, 17 Nov 2012 07:29:57 -0500
From: Charles Philip Chan <cpchan@bell.net>
Subject: Re: [CEDET-devel] Cedet from bzr and Emacs
To: cedet-devel@lists.sourceforge.net
Message-ID: <87d2zcqunu.fsf@karnak.MagnumOpus.khem>
Content-Type: text/plain; charset="us-ascii"

David Engster <deng@randomsample.de> writes:

Hi David:

> You are using an old Emacs development snapshot. Please upgrade to a
> stable Emacs release, or the current bzr snapshot.

Huh, I am using the current Emacs devel version from bzr. The current
stable version is 24.2 (dated August 27, 2012).


Why use Windows, since there is a door?
(By fachat@galileo.rhein-neckar.de, Andre Fachat)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available


Message: 5
Date: Sun, 18 Nov 2012 20:35:56 +0100
From: David Engster <deng@randomsample.de>
Subject: Re: [CEDET-devel] Cedet from bzr and Emacs
To: Charles Philip Chan <cpchan@bell.net>
Cc: cedet-devel@lists.sourceforge.net
Message-ID: <87lidyn1pf.fsf@randomsample.de>
Content-Type: text/plain

Charles Philip Chan writes:
> David Engster <deng@randomsample.de> writes:
> Hi David:
>> You are using an old Emacs development snapshot. Please upgrade to a
>> stable Emacs release, or the current bzr snapshot.
> Huh, I am using the current Emacs devel version from bzr. The current
> stable version is 24.2 (dated August 27, 2012).

You are right, of course. I'm still on the current emacs-24 branch,
totally forgot that version was bumped on trunk and somehow misread your
version as "23.3.50". Sorry for that.

Anyway, I tried with latest trunk and it worked without problems. Please

bzr revert
bzr clean-tree
bzr clean-tree --ignore

to get a clean checkout and be sure that 'make' really uses the correct
Emacs binary by doing

make EMACS=<your emacs-snapshot binary>

If it still fails, please show how you load CEDET in your init file and
try to provide a backtrace so I can see where this recursion is



Message: 6
Date: Mon, 19 Nov 2012 14:34:53 +0100 (CET)
From: Damien DEVILLE <damien.deville@netasq.com>
Subject: Re: [CEDET-devel] Disappearing buffers
To: David Engster <deng@randomsample.de>
Cc: John Wiegley <jwiegley@gmail.com>, cedet-devel@lists.sf.net,        "Eric
        M. Ludlam" <eric@siege-engine.com>
Message-ID: <312206354.5100546.1353332093559.JavaMail.root@work>
Content-Type: text/plain; charset=utf-8

Hi List,

The fix seems to be working, thanks for it, i can now use semanticdb with gtags and it is faster than before


----- Original Message -----
> Eric M. Ludlam writes:
> > On 03/18/2010 10:14 AM, Damien Deville wrote:
> >> I have some C code which define one static function foo then uses
> >> it in
> >> another function, when placing cursor at the start of foo() and
> >> waiting
> >> for idle-summary timer to expire, my buffer get closed and I have
> >> the
> >> following error in *Messages* buffer
> >
> > What feature is using the below in the idle timer?  I cannot find a
> > call
> > to semantic-symref-result-get-tags in anything that is called from
> > the
> > idle timer except for the use of gnu global as a database backend.
> >
> > Even in that case, the purpose is to close buffers that weren't
> > already
> > open.  The earlier block of code in that function attempts to do
> > that
> > with get-file-buffer.  If the database return is retrieving a file
> > name
> > for which get-file-buffer fails, but find-file-noselect succeeds,
> > well
> > that's kind of interesting.  What do you think that might be?
> After 2.5 years I was finally hit by the same thing. And I think I
> fixed
> it. So If you've ditched CEDET because of that bug, now would be a
> good
> time to try again. :-)
> At least my case was actually pretty simple: I was working in a
> directory which was a symlink. However, GNU global always follows
> symlinks and returns "true" filenames, while `get-file-buffer' does
> *not* dereference them. So if you were visiting ~/foo-symlink/test.c,
> a
> global search returns ~/foo/test.c and Semantic would happily kill
> your
> buffer.
> And why do the most notorious bugs always have the simplest fixes?
> --- lisp/cedet/semantic/symref.el     2012-09-02 16:59:23 +0000
> +++ lisp/cedet/semantic/symref.el     2012-11-06 16:15:02 +0000
> @@ -356,7 +356,7 @@
>         (lambda (hit)
>           (let* ((line (car hit))
>                  (file (cdr hit))
> -                (buff (get-file-buffer file))
> +                (buff (find-buffer-visiting file))
>                  (tag nil)
>                  )
>             (cond
> -David


Message: 7
Date: Mon, 19 Nov 2012 14:33:04 +0000
From: Miguel Guedes <miguel.a.guedes@gmail.com>
Subject: [CEDET-devel] [PATCH] contrib: small fix for
To: cedet-devel@lists.sf.net
Message-ID: <50AA4320.5090401@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Patch below fixes contrib/cedet-contrib-load not loading the correct

/usr/src/bzr-cedet/contrib$ bzr diff
=== modified file 'contrib/cedet-contrib-load.el'
--- contrib/cedet-contrib-load.el       2010-09-15 20:32:13 +0000
+++ contrib/cedet-contrib-load.el       2012-11-19 14:29:22 +0000
@@ -29,7 +29,7 @@

  ;;; Contrib autoloads
-(load "contrib/loaddefs" nil t)
+(load "contrib/contrib-loaddefs" nil t)

  (provide 'cedet-contrib-load)



Message: 8
Date: Tue, 20 Nov 2012 17:13:29 +0100
From: Alex Ott <alexott@gmail.com>
Subject: Re: [CEDET-devel] EDE projects for JVM-related languages &
        build   tools
To: "Eric M. Ludlam" <ericludlam@gmail.com>
Cc: cedet-devel <cedet-devel@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1

Hello Eric

I found some problems with autoload projects - I'm defining a project
class for Leiningen - Clojure build tool. It's similar to Maven
project type - I defined corresponding load & finding root functions,
and have in module following code.

 (ede-project-autoload "lein2"
                       :name "Lein2"
                       :file 'ede/proj-lein2
                       :proj-file "project.clj"
                       :proj-root 'ede-lein2-project-root
                       :load-type 'ede-lein2-load
                       :class-sym 'ede-lein2-project
                       :new-p nil
                       :safe-p t

It looks like it working, because I'm able to compile project, staying
in some clojure source file. But I can't retrieve current project with
- ede-current-project function - it always returns nil, although, in
the same situation, Maven-based projects always have
ede-object-project variable filled with corresponding instance of
maven class.

Do I need to add some special code to automatically fill
ede-object-project variable?

With best wishes,                    Alex Ott
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott


Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!


Cedet-devel mailing list

End of Cedet-devel Digest, Vol 78, Issue 11