CEDET

Hello List,

I have a few custom Srecode srt templates in ~/.srecode which 
override/extend Srecode's own built-in templates. Unfortunately Srecode 
doesn't seem to compile and load them when emacs first starts and I'm 
forced to load each template individually and hit C-c to compile them so 
that Srecode finally recognises them.

I'm pretty sure there is a setting somewhere to instruct Srecode to do 
this automatically; if so, anyone knows what it is?


-- 
Miguel

>>>>> "D" == Daimrod  <daimrod@...> writes:

    D> Hi,
    D> I'm using the latest emacs (compiled from git) and I use python-mode
    D> (from bzr) instead of the built-in mode python.el.

    D> I've encountered this bug[1], however, `python-proc' is now deprecated
    D> and should be replaced by `python-shell-internal-get-or-create-process'.
    D> And that's cool, because python-mode uses the same name.

    D> Could semantic use `python-shell-internal-get-or-create-process' instead
    D> of the old `python-proc'?

    D> It just need to be replaced in
    D> wisent/python.el::semantic-python-get-system-include-path

    D> [1]http://comments.gmane.org/gmane.emacs.cedet/5512

    D> ------------------------------------------------------------------------------
    D> Don't let slow site performance ruin your business. Deploy New Relic APM
    D> Deploy New Relic app performance management and know exactly
    D> what is happening inside your Ruby, Python, PHP, Java, and .NET app
    D> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
    D> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
    D> Cedet-devel mailing list
    D> Cedet-devel@...
    D> https://lists.sourceforge.net/lists/listinfo/cedet-devel

I also encountered this bug. I think there are too many branches of
python mode in emacs. It leads to chaoes for setting python
configuration in emacs. They should be renovated and integrated.

Best wishes,

Easior 
------ 
"It was the age of wisdom, it was the age of foolishness, it was the
epoch of belief, it was the epoch of incredulity, it was the season of
Light, it was the season of Darkness, it was the spring of hope, it
was the winter of despair, we had everything before us, we had nothing
before us, we were all going direct to heaven, we were all going
direct the other way - in short, the period was so far like the
present period, that some of its noisiest authorities insisted on its
being received, for good or for evil, in the superlative degree of
comparison only."

                               TALES OF TWO CITIES, by Charles Dickens

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

-- 
Yours sincerely,

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

С уважением,

Владимир Казанов,
программист,
моб. +7 (963) 304-05-12
ICQ 82042707
skype: stvovka
эл.почта vkazanov@...

On 11/07/2012 12:59 PM, Dan Debertin wrote:
> Are there any other tags I should generate that would be useful? I see
> that other grammars (notably Python) generate CODE-TAGs all over the
> place; how (if at all) are those used by CEDET?

Hi Dan,

David did a good job answering your other questions, but I can answer 
this one.  Sorry for the late reply.

CODE tags are used by the parser to mark blocks of code that can't be 
tied to a function  or other construct directly.  The CODE tag's primary 
use is with the incremental parser defining some bounds within which to 
restrict the partial reparse.  If the code was instead marked as 
unmatched, then your edits might affect other live tags nearby, and more 
code would need to be partially reparsed.  I can't recall all the rules 
there, but tagging code in the Emacs Lisp parser this way was helpful. 
It probably helps with the local-context parsers too.

What that means is, if you already have all your functions defined, and 
the function includes the code block, then no need to keep going.  If 
Scala really has code just sitting about unowned by some other well 
defined construct, then a code tag would be useful, but there is no real 
need to parse the code.  Just identify the space it takes up, and 
possibly identify a name.

Hope that helps.
Eric

Hi Alex,

Sorry for the delay.

I added you as a tracker admin so you can update the bugs/tasks.

Thanks!
Eric

On 11/07/2012 05:53 AM, Alex Ott wrote:
> Hi
>
> I have following question - do CEDET's bug tracker requires special
> permissions to make changes in bugs or not?
> I just want to go through list of opened issues, and close
> outdated/resolved or irrelevant (like
> https://sourceforge.net/tracker/?func=detail&aid=2989180&group_id=17886&atid=117886),
> but I can't do anything with them, even to assign some bugs to me...
>

Hi All,

Sorry for being late replying to this thread.  I've was busy throwing 
pumpkins in Delaware, and then recovering, and building a web-site for 
it over at siege-engine.com.

I'm glad you guys are looking into this problem.  I'd been wondering how 
to get that stuff to work.  It was ok for Android projects, since 
Android used one big jar file, but regular Java programs eluded me, 
mostly due to the path issues.

I had to solve a similar problem for Arduino projects.  Arduino code is 
C++, but the build system automatically sticks an include of wiring.h 
into the file before compilation by the c++ compiler.

If you look at ede/arduino.el, there is one trick of including the 
wiring macros into the preprocessor, and in semantic/bovine/c.el look 
for arduino-mode, and you will see an overload of 
semantic-find-tags-included.  This will get all the include file lookup 
code to use the extra headers as needed.

Here is a little bit of my philosophy about the proposed use 
semantic-after-toplevel-cache-change-hook:

In my mind, a language specific customization should be supported via 
different function overrides.  If it isn't supportable, I'd like to see 
a new override-able function for the desired purpose.  Project related 
changes, of course, can be similarly supported via EDE, except via methods.

My interpretation of your suggestion below is to insert faux tags into 
the regular tag stream for the Java files. ?  I think it is best to keep 
that pure when possible.

That said, this is similar to the Pirate Code.  More of a guideline than 
a rule. :)  In this case though, I think there is good support in these 
other two areas.

Thanks!
Eric

On 11/07/2012 11:42 AM, Alex Ott wrote:
> I thought about implicit expansion in
> semantic-after-toplevel-cache-change-hook also because it would
> possible to provide support for 'import something.*;' - in this case,
> we could search for classes in given package, and inject them into
> current tag cache
>
> On Wed, Nov 7, 2012 at 9:27 AM, Vladimir Kazanov<vkazanov@...>  wrote:
>>
>>
>> Alex,
>>
>> I think I am pretty close to solving this problem. As far as I can see,
>> semanticdb-typecache-find java-specific override should be fixed to take in
>> account java.lang.* searches, as all the tags required are already
>> accessible.
>>
>> For example, the following code gives me nice String method completions
>> (java.lang.String is not imported):
>>
>> java.lang.String tst;
>> tst. // completion follow
>>
>> The point is that typecache searches should also check if there is
>> java.lang.Smth, not just Smth.
>>
>> On Wed, Nov 7, 2012 at 2:58 PM, Alex Ott<alexott@...>  wrote:
>>>
>>> Yes, I received the patch, slightly modified it and currently trying
>>> to implement name completion for built-in java classes.
>>>
>>> My idea is to get list of built-in classes and inject them into tags,
>>> but I'm currently not sure how it's better to make this - I thought
>>> about use of semantic-after-toplevel-cache-change-hook - but we need
>>> to have this only for java-mode, and in description of this hook there
>>> is notification about potential problems if it will become mode-local.
>>>
>>> Maybe somebody has other ideas? I think, that this isn't Java-specific
>>> problem, Python also has modules that automatically imported during
>>> startup...
>>>
>>> On Mon, Nov 5, 2012 at 8:30 PM, David Engster<deng@...>
>>> wrote:
>>>> Vladimir Kazanov writes:
>>>>> The diff attached is a fix of the very first problem I noticed:
>>>>> java.lang
>>>>> package is not included for auto-completion. The code is simple, it
>>>>> uses the
>>>>> new JDK-locating function to to get the appropriate table from the JDK
>>>>> jar
>>>>> file.
>>>>>
>>>>> This is a rather quick and obvious fix, but it works for me.
>>>>
>>>> Thank you for the patch! Regarding the actual content, I hope Alex will
>>>> chime in, since I'm not familiar with the Java code. I'm only here to
>>>> give you the standard blurb: ;-)
>>>>
>>>> While this patch is still small enough to qualify as a so called "tiny
>>>> change", if you plan on submitting further fixes, the FSF will need
>>>> signed papers from you. This is required because CEDET is merged with
>>>> GNU Emacs. If you need help with that, please let me know.
>>>>
>>>> -David
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>> Stay in control, update software, and manage PCs from one command center
>>>> Diagnose problems and improve visibility into emerging IT issues
>>>> Automate, monitor and manage. Do more in less time with Central
>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>> _______________________________________________
>>>> Cedet-devel mailing list
>>>> Cedet-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>>
>>>
>>>
>>> --
>>> With best wishes,                    Alex Ott
>>> http://alexott.net/
>>> Twitter: alexott_en (English), alexott (Russian)
>>> Skype: alex.ott
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Cedet-devel mailing list
>>> Cedet-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>>
>>
>> --
>> Yours sincerely,
>>
>> Vladimir Kazanov,
>> software developer,
>> mob. +7 (963) 304-05-12
>>
>>
>> ICQ: 82042707
>> skype: stvovka
>> email: vkazanov@...
>> --
>>
>> С уважением,
>>
>> Владимир Казанов,
>> программист,
>> моб. +7 (963) 304-05-12
>>
>>
>> ICQ 82042707
>> skype: stvovka
>> эл.почта vkazanov@...
>
>
>

在 2012-11-21 AM12:14， <cedet-devel-request@...>写道：

> Send Cedet-devel mailing list submissions to
>         cedet-devel@...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/cedet-devel
> or, via email, send a message with subject or body 'help' to
>         cedet-devel-request@...
>
> You can reach the person managing the list at
>         cedet-devel-owner@...
>
> 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 24.3.50.1 (Charles Philip Chan)
>    5. Re: Cedet from bzr and Emacs 24.3.50.1 (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@...>
> Subject: [CEDET-devel] Java and static/instance context
> To: Cedet-devel@...
> Message-ID:
>         <CAAs=
> 0-2wfaqmdvbjaoEK+UtEuZB6VhRvpytTn_+PxeHffk7jAw@...>
> 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
> reasonable?
>
> --
> Yours sincerely,
>
> Vladimir Kazanov,
> software developer,
> mob. +7 (963) 304-05-12
> ICQ: 82042707
> skype: stvovka
> email: vkazanov@...
> --
>
> ? ?????????,
>
> ???????? ???????,
> ???????????,
> ???. +7 (963) 304-05-12
> ICQ 82042707
> skype: stvovka
> ??.????? vkazanov@...
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Nov 2012 21:51:11 +0100
> From: David Engster <deng@...>
> Subject: Re: [CEDET-devel] semanticdb db-mk.el wrong path?
> To: Zhenchao Li <cockneykevin@...>
> Cc: cedet-devel@...
> Message-ID: <871ufvsybk.fsf@...>
> 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.
>
> -David
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 15 Nov 2012 20:28:43 +0100
> From: David Engster <deng@...>
> Subject: Re: [CEDET-devel] Setting up to browse madwifi
> To: Maindoor <sanjeevfiles@...>
> Cc: "cedet-devel@..."
>         <cedet-devel@...>
> Message-ID: <87wqxmr7h0.fsf@...>
> 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.
>
> -David
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 17 Nov 2012 07:29:57 -0500
> From: Charles Philip Chan <cpchan@...>
> Subject: Re: [CEDET-devel] Cedet from bzr and Emacs 24.3.50.1
> To: cedet-devel@...
> Message-ID: <87d2zcqunu.fsf@...>
> Content-Type: text/plain; charset="us-ascii"
>
> David Engster <deng@...> 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).
>
> Regards,
> Charles
>
> --
> Why use Windows, since there is a door?
> (By fachat@..., 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@...>
> Subject: Re: [CEDET-devel] Cedet from bzr and Emacs 24.3.50.1
> To: Charles Philip Chan <cpchan@...>
> Cc: cedet-devel@...
> Message-ID: <87lidyn1pf.fsf@...>
> Content-Type: text/plain
>
> Charles Philip Chan writes:
> > David Engster <deng@...> 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
> do
>
> 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
> happening.
>
> Thanks,
> David
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 19 Nov 2012 14:34:53 +0100 (CET)
> From: Damien DEVILLE <damien.deville@...>
> Subject: Re: [CEDET-devel] Disappearing buffers
> To: David Engster <deng@...>
> Cc: John Wiegley <jwiegley@...>, cedet-devel@...,
>  "Eric
>         M. Ludlam" <eric@...>
> Message-ID: <312206354.5100546.1353332093559.JavaMail.root@...>
> 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
>
> Damien
>
> ----- 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@...>
> Subject: [CEDET-devel] [PATCH] contrib: small fix for
>         cedet-contrib-load
> To: cedet-devel@...
> Message-ID: <50AA4320.5090401@...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Patch below fixes contrib/cedet-contrib-load not loading the correct
> library.
>
>
> /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)
>
>
> --
> Miguel
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 20 Nov 2012 17:13:29 +0100
> From: Alex Ott <alexott@...>
> Subject: Re: [CEDET-devel] EDE projects for JVM-related languages &
>         build   tools
> To: "Eric M. Ludlam" <ericludlam@...>
> Cc: cedet-devel <cedet-devel@...>
> Message-ID:
>         <CALV1_=
> L1Mn41o1pBLtMXzaZF5FWRGTmX5ZkN+UV04YHpeX4KjA@...>
> 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-add-project-autoload
>  (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
> http://alexott.net/
> 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!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
> ------------------------------
>
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
>
> End of Cedet-devel Digest, Vol 78, Issue 11
> *******************************************
>

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-add-project-autoload
 (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
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

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


/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)


-- 
Miguel

Hi List,

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

Damien

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

David Engster <deng@...> 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).

Regards,
Charles

-- 
Why use Windows, since there is a door?
(By fachat@..., Andre Fachat)

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.

-David

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.

-David

Hi, everyone!

Does anyone know how quick FSF is about sending legal papers? I've sent the
request last week, but still did not get a reply.

It seems that Alex is busy these days, so I started fixing Java-related
bugs in my local branch. At least one of them can be considered critical,
and it would definitely be really nice to see the fix in the repository.
:-(

-- 
Yours sincerely,

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

С уважением,

Владимир Казанов,
программист,
моб. +7 (963) 304-05-12
ICQ 82042707
skype: stvovka
эл.почта vkazanov@...

John.Pfeiffer@... wrote:
>
> Hello,
>
> Has anyone done any work on CEDET support for SystemVerilog?
>
> I saw some postings from a couple of years ago, but I’m not sure if anything came of it.
>
> If so, could you send me the code so I could help out with support?
>

Hi John!

I did a trial beginning 2011, I tagged it 0.0 for a sensible reason ;) ; my attempt was an almost direct derivation of the 2005 IEEE 1800 SystemVerilog Standard Annex A [Formal Syntax], with the strictly needed LALR rewriting, and a few other "embellishments", to get a source for wisent. It flourished into about a thousand conflicts, as far as I remember; if you like I can share that with you.

It contains 382 terminals, 1063 nonterminals and 3402 production rules.

I've just checked, and seen I sent it to Wilson Snyder, one of the two maintainers of the amazing Verilog mode (and author of the auto extensions, AFAIK), in March 2011; as far as I can tell it didn't go into anything, hence I'm afraid it won't be of much aid for us either.

I used it with the CEDET 1.0, and I did not update it any further.

BTW, it would make sense to update the grammar to the 2009 version (I got that afterward).

Please find attached the grammar graph (an arc goes from A to B if a production rule with LHS A has B in the RHS); please write me if you want to have a crack at it.

Cheers,

Andrea.