CEDET

Hi,

CEDET was certainly designed to work cross-language, as it provides a 
single API that works across all languages, with a secondary API for 
working across languages that have basic structure, like javascript or C.

Unfortunately, I'm not a Java or JDEE expert.

The basic strategy is to get an EDE project pointing to the root of all 
your code.  I'm assuming all the languages you mentioned are in one big 
mega-project.  That top level project then needs to know about all the 
targets.  For simplicity sake, you could have one target per language 
type, or more detailed, one target per language/directory.

That sounds good, but no-one has written such a generic project.  If you 
feel adventurous, you could copy ede-emacs.el to your own thing, and 
change ede-emacs-project-root to ede-myproject-project-root and fix the 
directory detection.  The framework for rolling your own is pretty easy 
from there.

If all else fails, you can just use ede-cpp-root, and it will deal with 
your c++ code fine, and provide a simple root-of-project for all the 
cross referencing functions.

As for all your languages, each language has varying levels of support 
based on how much effort the folks who use that language have chosen to 
put into it.  In the JDEE case, they have their own completion system. 
There have been projects to merge CEDET's from-source-only completion 
with JDEEs from-compiled-only parsing, but it has never been finished.

As for the symbol references, you can use any of the different tools you 
prefer, or none.  If you try it (once you have an EDE project specifying 
the root) with the find/grep solution and it is fast enough, then you 
can consider yourself done.

The simple-recipe version of the doc is in cedet/common/cedet.el where 
it will help based on what kind of task you have.  Your task isn't in 
there, but some aspects of it are.

If you have more specific questions, they may be easier to answer.

Eric

On 04/30/2010 03:40 PM, David Ventimiglia wrote:
> Hello,
>
> I’m sure versions of this newbie type question get asked again and again
> from time to time, but I just couldn’t pull together an answer for
> myself by sifting the CEDET list archives, so (apologies), I’ll ask away.
>
> What are some best practices for configuring CEDET for a Java-ish
> project, in order to achieve:
>
> * Smart completion
>
> * Symbol lookup
>
> * File name lookup
>
> * Cross-references
>
> I should point out that my "project" (as is quite common) has many file
> types besides Java: XML, HTML, JavaScript, some C/C++ code, etc., and
> I'd like to have a somewhat uniform Emacs view of all this. That's
> partly why JDEE project files don't quite do the trick.
>
> The problem I'm having is that the JDEE provides some version of these
> features, with some deficiencies, and seemingly with considerable
> overlap with CEDET. Completion and symbol lookup exist, but are slow and
> only work for compiled classes. Also, they only work for Java files,
> which is inadequate when a project has a mixture of other programming
> languages and file types. File name lookup seems not to exist at all.
> And JDEE has the xref database, but it's a little flaky (it pukes while
> parsing one of my files) and again, only works for Java files.
>
> So, I'd prefer to use CEDET's features for these. Evidently, it involves
> some combination of CEDET customizations, EDE project configuration, and
> maybe some use of idutils and/or GNU Global for good measure.
> Unfortunately, I haven't yet figured out how to do this, despite staring
> at the CEDET documentation for a few days. I'll keep plugging away at
> it, but I confess I'm badly in need of a clue on this. Thanks in
> advance. And I should say, I really am very impressed by CEDET (despite
> an imperfect understanding of it) and sense considerable power embedded
> in it.
>
> All the best,
>
> David Ventimiglia
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Thanks, Eric.  I've a few, more-specific questions spliced in below.

> The basic strategy is to get an EDE project pointing to the root of
all
> your code.  I'm assuming all the languages you mentioned are in one
big
> mega-project.  That top level project then needs to know about all the
> targets.  For simplicity sake, you could have one target per language
> type, or more detailed, one target per language/directory.

So far, I just started with ede-simple-project, which I created with the
command ede-new while visiting a Java file buried deep in that part of
our source-tree.  This put a file in my $HOME/.ede directory defining
that ede-simple-project.  I also have run GNU Global in my project root.
What do I do now to enable completion, lookup, and cross-references for
symbols?  

> As for the symbol references, you can use any of the different tools
> you
> prefer, or none.  If you try it (once you have an EDE project
> specifying
> the root) with the find/grep solution and it is fast enough, then you
> can consider yourself done.

I made these customizations:

(require 'cedet)
(global-ede-mode 1)
(semanticdb-enable-gnu-global-databases 'java-mode)
(semanticdb-enable-gnu-global-databases 'jde-mode)
(setq ede-locate-setup-options
      '(ede-locate-global
        ede-locate-base))

But when I invoke the command semantic-symref-symbol on some symbol in a
Java file, I get the message:

semantic-symref-tool-grep - Needs to be configured for jde-mode

What does this mean?

Finally, must one use Global, idutils, locate, etc., to do symbol
lookups?  Is it possible just to rely on the CEDET tools alone?  What I
mean is, I gather that semantic is parsing and caching the tags for,
say, the Java files that I visit.  Is it possible to have semantic parse
ALL my Java source files ahead of time (a la Global, idutils, ctags,
etc.), then just use semanticdb to support completion, lookup, and
cross-referencing?  This isn't a huge deal, but I'm trying to evangelize
Emacs+CEDET+JDEE at my company, which is a Windows shop, and the more
external tools I have to integrate (like finding Windows versions of
Global, idutils, etc.), the harder that sell becomes.  Or, would it
simply be too much of a performance hit to ask semantic to do what
Global et al are optimized to do very fast?

Thanks!
Best,
David

On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> Thanks, Eric.  I've a few, more-specific questions spliced in below.
>
>> The basic strategy is to get an EDE project pointing to the root of
> all
>> your code.  I'm assuming all the languages you mentioned are in one
> big
>> mega-project.  That top level project then needs to know about all the
>> targets.  For simplicity sake, you could have one target per language
>> type, or more detailed, one target per language/directory.
>
> So far, I just started with ede-simple-project, which I created with the
> command ede-new while visiting a Java file buried deep in that part of
> our source-tree.  This put a file in my $HOME/.ede directory defining
> that ede-simple-project.  I also have run GNU Global in my project root.
> What do I do now to enable completion, lookup, and cross-references for
> symbols?

Ah, good idea with the simple project.  I'd forgotten about that.

If you look in cedet/common/cedet.info in the node:

(cedet.info)Top:: > GNU Global

It lists all the options for enabling GNU Global in a CEDET project.

>> As for the symbol references, you can use any of the different tools
>> you
>> prefer, or none.  If you try it (once you have an EDE project
>> specifying
>> the root) with the find/grep solution and it is fast enough, then you
>> can consider yourself done.
>
> I made these customizations:
>
> (require 'cedet)
> (global-ede-mode 1)
> (semanticdb-enable-gnu-global-databases 'java-mode)
> (semanticdb-enable-gnu-global-databases 'jde-mode)
> (setq ede-locate-setup-options
>        '(ede-locate-global
>          ede-locate-base))
>
> But when I invoke the command semantic-symref-symbol on some symbol in a
> Java file, I get the message:
>
> semantic-symref-tool-grep - Needs to be configured for jde-mode
>
> What does this mean?


That means that semantic-symref-filepattern-alist needs to be 
customized.  If you have a good customization, I'll add it to the 
default value.

Probably something like:

(add-to-list 'semantic-symref-filepattern-alist
	'(jde-mode "*.java"))

I'll fix the error message to be more obvious.

Of course, this also means that it failed to auto-detect the GNU Global 
tags file at the root of your project.  Use  M-x 
cedet-gnu-global-show-root to determine if the detection is working.  If 
it fails, then there is something in the Global doc that might help, 
since CEDET just calls global with "-pq" options.

> Finally, must one use Global, idutils, locate, etc., to do symbol
> lookups?  Is it possible just to rely on the CEDET tools alone?

The symref tool relies on at least one external tool, but it can use 
find/grep commands to do it, so the other tools are not required, but 
will instead provide better and faster results.

 >What I
> mean is, I gather that semantic is parsing and caching the tags for,
> say, the Java files that I visit.  Is it possible to have semantic parse

Semantic only parses the tags (like ctags) and not the contents.

> ALL my Java source files ahead of time (a la Global, idutils, ctags,
> etc.), then just use semanticdb to support completion, lookup, and
> cross-referencing?  This isn't a huge deal, but I'm trying to evangelize
> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the more
> external tools I have to integrate (like finding Windows versions of
> Global, idutils, etc.), the harder that sell becomes.  Or, would it
> simply be too much of a performance hit to ask semantic to do what
> Global et al are optimized to do very fast?

Semantic parses it's own tags because tools like global and ctags 
provide only "quickie" information, and take many short-cuts to do so. 
To do what CEDET does with tags, it needs to be much more careful.

Semantic also already has trouble with really huge projects, and Emacs 
Lisp is just the wrong language to implement symbol cross-reference 
database in do the shear size.

Instead, things like Global do a pretty good job on references, so I use 
those instead, and deal with the inaccuracy of it.  I'm hoping to 
double-check each "hit" with a real analysis to prove that the hit is 
really a reference to a given symbol, and not some side-effect of 
polymorphism or other trick.

Anyway, Global is probably your best bet unless find/grep is fast enough 
for you.

Good Luck!
Eric

Thanks, Eric.  I think it might be working for me.  At least, when I do
semantic-symref on a Java function in my project, I get a buffer with a
list of references.  It's a little slow, however, and I'm wondering if
it's falling back on Grep and not using my Global tags files.  The
command cedet-gnu-global-show-root does show the right project root,
however.  

Question:  is there a way to verify it's using Global and not Grep?  

Thanks!
Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Sunday, May 02, 2010 5:47 AM
> To: David Ventimiglia
> Cc: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> > Thanks, Eric.  I've a few, more-specific questions spliced in below.
> >
> >> The basic strategy is to get an EDE project pointing to the root of
> > all
> >> your code.  I'm assuming all the languages you mentioned are in one
> > big
> >> mega-project.  That top level project then needs to know about all
> the
> >> targets.  For simplicity sake, you could have one target per
> language
> >> type, or more detailed, one target per language/directory.
> >
> > So far, I just started with ede-simple-project, which I created with
> the
> > command ede-new while visiting a Java file buried deep in that part
> of
> > our source-tree.  This put a file in my $HOME/.ede directory
defining
> > that ede-simple-project.  I also have run GNU Global in my project
> root.
> > What do I do now to enable completion, lookup, and cross-references
> for
> > symbols?
> 
> Ah, good idea with the simple project.  I'd forgotten about that.
> 
> If you look in cedet/common/cedet.info in the node:
> 
> (cedet.info)Top:: > GNU Global
> 
> It lists all the options for enabling GNU Global in a CEDET project.
> 
> >> As for the symbol references, you can use any of the different
tools
> >> you
> >> prefer, or none.  If you try it (once you have an EDE project
> >> specifying
> >> the root) with the find/grep solution and it is fast enough, then
> you
> >> can consider yourself done.
> >
> > I made these customizations:
> >
> > (require 'cedet)
> > (global-ede-mode 1)
> > (semanticdb-enable-gnu-global-databases 'java-mode)
> > (semanticdb-enable-gnu-global-databases 'jde-mode)
> > (setq ede-locate-setup-options
> >        '(ede-locate-global
> >          ede-locate-base))
> >
> > But when I invoke the command semantic-symref-symbol on some symbol
> in a
> > Java file, I get the message:
> >
> > semantic-symref-tool-grep - Needs to be configured for jde-mode
> >
> > What does this mean?
> 
> 
> That means that semantic-symref-filepattern-alist needs to be
> customized.  If you have a good customization, I'll add it to the
> default value.
> 
> Probably something like:
> 
> (add-to-list 'semantic-symref-filepattern-alist
> 	'(jde-mode "*.java"))
> 
> I'll fix the error message to be more obvious.
> 
> Of course, this also means that it failed to auto-detect the GNU
Global
> tags file at the root of your project.  Use  M-x
> cedet-gnu-global-show-root to determine if the detection is working.
> If
> it fails, then there is something in the Global doc that might help,
> since CEDET just calls global with "-pq" options.
> 
> > Finally, must one use Global, idutils, locate, etc., to do symbol
> > lookups?  Is it possible just to rely on the CEDET tools alone?
> 
> The symref tool relies on at least one external tool, but it can use
> find/grep commands to do it, so the other tools are not required, but
> will instead provide better and faster results.
> 
>  >What I
> > mean is, I gather that semantic is parsing and caching the tags for,
> > say, the Java files that I visit.  Is it possible to have semantic
> parse
> 
> Semantic only parses the tags (like ctags) and not the contents.
> 
> > ALL my Java source files ahead of time (a la Global, idutils, ctags,
> > etc.), then just use semanticdb to support completion, lookup, and
> > cross-referencing?  This isn't a huge deal, but I'm trying to
> evangelize
> > Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
more
> > external tools I have to integrate (like finding Windows versions of
> > Global, idutils, etc.), the harder that sell becomes.  Or, would it
> > simply be too much of a performance hit to ask semantic to do what
> > Global et al are optimized to do very fast?
> 
> Semantic parses it's own tags because tools like global and ctags
> provide only "quickie" information, and take many short-cuts to do so.
> To do what CEDET does with tags, it needs to be much more careful.
> 
> Semantic also already has trouble with really huge projects, and Emacs
> Lisp is just the wrong language to implement symbol cross-reference
> database in do the shear size.
> 
> Instead, things like Global do a pretty good job on references, so I
> use
> those instead, and deal with the inaccuracy of it.  I'm hoping to
> double-check each "hit" with a real analysis to prove that the hit is
> really a reference to a given symbol, and not some side-effect of
> polymorphism or other trick.
> 
> Anyway, Global is probably your best bet unless find/grep is fast
> enough
> for you.
> 
> Good Luck!
> Eric
> 
> 
>

If you use semantic-symref-data-debug-last-result it will show the 
object that contains the data, and it is named after the tool it uses, 
like grep or global.

Eric

On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> Thanks, Eric.  I think it might be working for me.  At least, when I do
> semantic-symref on a Java function in my project, I get a buffer with a
> list of references.  It's a little slow, however, and I'm wondering if
> it's falling back on Grep and not using my Global tags files.  The
> command cedet-gnu-global-show-root does show the right project root,
> however.
>
> Question:  is there a way to verify it's using Global and not Grep?
>
> Thanks!
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Sunday, May 02, 2010 5:47 AM
>> To: David Ventimiglia
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  I've a few, more-specific questions spliced in below.
>>>
>>>> The basic strategy is to get an EDE project pointing to the root of
>>> all
>>>> your code.  I'm assuming all the languages you mentioned are in one
>>> big
>>>> mega-project.  That top level project then needs to know about all
>> the
>>>> targets.  For simplicity sake, you could have one target per
>> language
>>>> type, or more detailed, one target per language/directory.
>>>
>>> So far, I just started with ede-simple-project, which I created with
>> the
>>> command ede-new while visiting a Java file buried deep in that part
>> of
>>> our source-tree.  This put a file in my $HOME/.ede directory
> defining
>>> that ede-simple-project.  I also have run GNU Global in my project
>> root.
>>> What do I do now to enable completion, lookup, and cross-references
>> for
>>> symbols?
>>
>> Ah, good idea with the simple project.  I'd forgotten about that.
>>
>> If you look in cedet/common/cedet.info in the node:
>>
>> (cedet.info)Top::>  GNU Global
>>
>> It lists all the options for enabling GNU Global in a CEDET project.
>>
>>>> As for the symbol references, you can use any of the different
> tools
>>>> you
>>>> prefer, or none.  If you try it (once you have an EDE project
>>>> specifying
>>>> the root) with the find/grep solution and it is fast enough, then
>> you
>>>> can consider yourself done.
>>>
>>> I made these customizations:
>>>
>>> (require 'cedet)
>>> (global-ede-mode 1)
>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>> (setq ede-locate-setup-options
>>>         '(ede-locate-global
>>>           ede-locate-base))
>>>
>>> But when I invoke the command semantic-symref-symbol on some symbol
>> in a
>>> Java file, I get the message:
>>>
>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>
>>> What does this mean?
>>
>>
>> That means that semantic-symref-filepattern-alist needs to be
>> customized.  If you have a good customization, I'll add it to the
>> default value.
>>
>> Probably something like:
>>
>> (add-to-list 'semantic-symref-filepattern-alist
>> 	'(jde-mode "*.java"))
>>
>> I'll fix the error message to be more obvious.
>>
>> Of course, this also means that it failed to auto-detect the GNU
> Global
>> tags file at the root of your project.  Use  M-x
>> cedet-gnu-global-show-root to determine if the detection is working.
>> If
>> it fails, then there is something in the Global doc that might help,
>> since CEDET just calls global with "-pq" options.
>>
>>> Finally, must one use Global, idutils, locate, etc., to do symbol
>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>
>> The symref tool relies on at least one external tool, but it can use
>> find/grep commands to do it, so the other tools are not required, but
>> will instead provide better and faster results.
>>
>>   >What I
>>> mean is, I gather that semantic is parsing and caching the tags for,
>>> say, the Java files that I visit.  Is it possible to have semantic
>> parse
>>
>> Semantic only parses the tags (like ctags) and not the contents.
>>
>>> ALL my Java source files ahead of time (a la Global, idutils, ctags,
>>> etc.), then just use semanticdb to support completion, lookup, and
>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>> evangelize
>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> more
>>> external tools I have to integrate (like finding Windows versions of
>>> Global, idutils, etc.), the harder that sell becomes.  Or, would it
>>> simply be too much of a performance hit to ask semantic to do what
>>> Global et al are optimized to do very fast?
>>
>> Semantic parses it's own tags because tools like global and ctags
>> provide only "quickie" information, and take many short-cuts to do so.
>> To do what CEDET does with tags, it needs to be much more careful.
>>
>> Semantic also already has trouble with really huge projects, and Emacs
>> Lisp is just the wrong language to implement symbol cross-reference
>> database in do the shear size.
>>
>> Instead, things like Global do a pretty good job on references, so I
>> use
>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>> double-check each "hit" with a real analysis to prove that the hit is
>> really a reference to a given symbol, and not some side-effect of
>> polymorphism or other trick.
>>
>> Anyway, Global is probably your best bet unless find/grep is fast
>> enough
>> for you.
>>
>> Good Luck!
>> Eric
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Thanks, Eric.  Unfortunately, it resolutely insists on using grep, or
nothing at all, and I'm afraid there still must be something fundamental
I'm misunderstanding.  I made customizations in stepwise fashion:

Step 1:  Added to .emacs
(require 'cedet)
(semantic-load-enable-code-helpers)
(global-ede-mode 1)
Result:  semantic-symref works, but uses grep

Step 2:  Added to .emacs
(require 'ede-locate)
(setq ede-locate-setup-options
      '(ede-locate-global
        ede-locate-base))
Result:  semantic-symref works, but uses grep

Step 3:  Added to .emacs
(require 'semantic-symref-grep) 
(add-to-list 'semantic-symref-filepattern-alist '(jde-mode "*.java"))
(add-to-list 'semantic-symref-filepattern-alist '(java-mode "*.java"))
Result:  semantic-symref works, but uses grep

Step 4:  Used ede-new to create a Simple project, which landed in
%HOME%/.ede/
Result:  semantic-symref fails, reporting "No references found".

Here's what the file in %HOME%/.ede/ looks like, where the contents of
:directory and :file just refer to things in my particular project
directory tree:
;; Object cc
;; EDE Simple Project
(ede-simple-project "cc"
  :name "cc"
  :directory
"c:/dev/eng/cc/denali/active/core/app-cc/cc/src/com/guidewire/cc/domain/
financials/impl/"
  :file
"!drive_c!dev!eng!cc!denali!active!core!app-cc!cc!src!com!guidewire!cc!d
omain!financials!impl!ProjSimple.ede"
  :targets 'nil
  )

I must be missing something, but I'm afraid I just can't see what it is.

Best,
David


> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 1:26 PM
> To: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> If you use semantic-symref-data-debug-last-result it will show the
> object that contains the data, and it is named after the tool it uses,
> like grep or global.
> 
> Eric
> 
> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> > Thanks, Eric.  I think it might be working for me.  At least, when I
> do
> > semantic-symref on a Java function in my project, I get a buffer
with
> a
> > list of references.  It's a little slow, however, and I'm wondering
> if
> > it's falling back on Grep and not using my Global tags files.  The
> > command cedet-gnu-global-show-root does show the right project root,
> > however.
> >
> > Question:  is there a way to verify it's using Global and not Grep?
> >
> > Thanks!
> > Best,
> > David
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Sunday, May 02, 2010 5:47 AM
> >> To: David Ventimiglia
> >> Cc: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  I've a few, more-specific questions spliced in
> below.
> >>>
> >>>> The basic strategy is to get an EDE project pointing to the root
> of
> >>> all
> >>>> your code.  I'm assuming all the languages you mentioned are in
> one
> >>> big
> >>>> mega-project.  That top level project then needs to know about
all
> >> the
> >>>> targets.  For simplicity sake, you could have one target per
> >> language
> >>>> type, or more detailed, one target per language/directory.
> >>>
> >>> So far, I just started with ede-simple-project, which I created
> with
> >> the
> >>> command ede-new while visiting a Java file buried deep in that
part
> >> of
> >>> our source-tree.  This put a file in my $HOME/.ede directory
> > defining
> >>> that ede-simple-project.  I also have run GNU Global in my project
> >> root.
> >>> What do I do now to enable completion, lookup, and
cross-references
> >> for
> >>> symbols?
> >>
> >> Ah, good idea with the simple project.  I'd forgotten about that.
> >>
> >> If you look in cedet/common/cedet.info in the node:
> >>
> >> (cedet.info)Top::>  GNU Global
> >>
> >> It lists all the options for enabling GNU Global in a CEDET
project.
> >>
> >>>> As for the symbol references, you can use any of the different
> > tools
> >>>> you
> >>>> prefer, or none.  If you try it (once you have an EDE project
> >>>> specifying
> >>>> the root) with the find/grep solution and it is fast enough, then
> >> you
> >>>> can consider yourself done.
> >>>
> >>> I made these customizations:
> >>>
> >>> (require 'cedet)
> >>> (global-ede-mode 1)
> >>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>> (setq ede-locate-setup-options
> >>>         '(ede-locate-global
> >>>           ede-locate-base))
> >>>
> >>> But when I invoke the command semantic-symref-symbol on some
symbol
> >> in a
> >>> Java file, I get the message:
> >>>
> >>> semantic-symref-tool-grep - Needs to be configured for jde-mode
> >>>
> >>> What does this mean?
> >>
> >>
> >> That means that semantic-symref-filepattern-alist needs to be
> >> customized.  If you have a good customization, I'll add it to the
> >> default value.
> >>
> >> Probably something like:
> >>
> >> (add-to-list 'semantic-symref-filepattern-alist
> >> 	'(jde-mode "*.java"))
> >>
> >> I'll fix the error message to be more obvious.
> >>
> >> Of course, this also means that it failed to auto-detect the GNU
> > Global
> >> tags file at the root of your project.  Use  M-x
> >> cedet-gnu-global-show-root to determine if the detection is
working.
> >> If
> >> it fails, then there is something in the Global doc that might
help,
> >> since CEDET just calls global with "-pq" options.
> >>
> >>> Finally, must one use Global, idutils, locate, etc., to do symbol
> >>> lookups?  Is it possible just to rely on the CEDET tools alone?
> >>
> >> The symref tool relies on at least one external tool, but it can
use
> >> find/grep commands to do it, so the other tools are not required,
> but
> >> will instead provide better and faster results.
> >>
> >>   >What I
> >>> mean is, I gather that semantic is parsing and caching the tags
> for,
> >>> say, the Java files that I visit.  Is it possible to have semantic
> >> parse
> >>
> >> Semantic only parses the tags (like ctags) and not the contents.
> >>
> >>> ALL my Java source files ahead of time (a la Global, idutils,
> ctags,
> >>> etc.), then just use semanticdb to support completion, lookup, and
> >>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >> evangelize
> >>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> > more
> >>> external tools I have to integrate (like finding Windows versions
> of
> >>> Global, idutils, etc.), the harder that sell becomes.  Or, would
it
> >>> simply be too much of a performance hit to ask semantic to do what
> >>> Global et al are optimized to do very fast?
> >>
> >> Semantic parses it's own tags because tools like global and ctags
> >> provide only "quickie" information, and take many short-cuts to do
> so.
> >> To do what CEDET does with tags, it needs to be much more careful.
> >>
> >> Semantic also already has trouble with really huge projects, and
> Emacs
> >> Lisp is just the wrong language to implement symbol cross-reference
> >> database in do the shear size.
> >>
> >> Instead, things like Global do a pretty good job on references, so
I
> >> use
> >> those instead, and deal with the inaccuracy of it.  I'm hoping to
> >> double-check each "hit" with a real analysis to prove that the hit
> is
> >> really a reference to a given symbol, and not some side-effect of
> >> polymorphism or other trick.
> >>
> >> Anyway, Global is probably your best bet unless find/grep is fast
> >> enough
> >> for you.
> >>
> >> Good Luck!
> >> Eric
> >>
> >>
> >>
> >
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> 
>
-----------------------------------------------------------------------
> -------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hi,

Did you you use the GNU global command  "gtags" to create the GLOBAL 
database for your code?  I don't remember if you mentioned doing that or 
not.  You need to create the GTAGS files before global will work on your 
code.

cedet-gnu-global-show-root

will tell you if it is detecting GLOBAL files associated with your 
directory or not.

Eric

On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> Thanks, Eric.  Unfortunately, it resolutely insists on using grep, or
> nothing at all, and I'm afraid there still must be something fundamental
> I'm misunderstanding.  I made customizations in stepwise fashion:
>
> Step 1:  Added to .emacs
> (require 'cedet)
> (semantic-load-enable-code-helpers)
> (global-ede-mode 1)
> Result:  semantic-symref works, but uses grep
>
> Step 2:  Added to .emacs
> (require 'ede-locate)
> (setq ede-locate-setup-options
>        '(ede-locate-global
>          ede-locate-base))
> Result:  semantic-symref works, but uses grep
>
> Step 3:  Added to .emacs
> (require 'semantic-symref-grep)
> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode "*.java"))
> (add-to-list 'semantic-symref-filepattern-alist '(java-mode "*.java"))
> Result:  semantic-symref works, but uses grep
>
> Step 4:  Used ede-new to create a Simple project, which landed in
> %HOME%/.ede/
> Result:  semantic-symref fails, reporting "No references found".
>
> Here's what the file in %HOME%/.ede/ looks like, where the contents of
> :directory and :file just refer to things in my particular project
> directory tree:
> ;; Object cc
> ;; EDE Simple Project
> (ede-simple-project "cc"
>    :name "cc"
>    :directory
> "c:/dev/eng/cc/denali/active/core/app-cc/cc/src/com/guidewire/cc/domain/
> financials/impl/"
>    :file
> "!drive_c!dev!eng!cc!denali!active!core!app-cc!cc!src!com!guidewire!cc!d
> omain!financials!impl!ProjSimple.ede"
>    :targets 'nil
>    )
>
> I must be missing something, but I'm afraid I just can't see what it is.
>
> Best,
> David
>
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 1:26 PM
>> To: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> If you use semantic-symref-data-debug-last-result it will show the
>> object that contains the data, and it is named after the tool it uses,
>> like grep or global.
>>
>> Eric
>>
>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  I think it might be working for me.  At least, when I
>> do
>>> semantic-symref on a Java function in my project, I get a buffer
> with
>> a
>>> list of references.  It's a little slow, however, and I'm wondering
>> if
>>> it's falling back on Grep and not using my Global tags files.  The
>>> command cedet-gnu-global-show-root does show the right project root,
>>> however.
>>>
>>> Question:  is there a way to verify it's using Global and not Grep?
>>>
>>> Thanks!
>>> Best,
>>> David
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>> To: David Ventimiglia
>>>> Cc: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
>> below.
>>>>>
>>>>>> The basic strategy is to get an EDE project pointing to the root
>> of
>>>>> all
>>>>>> your code.  I'm assuming all the languages you mentioned are in
>> one
>>>>> big
>>>>>> mega-project.  That top level project then needs to know about
> all
>>>> the
>>>>>> targets.  For simplicity sake, you could have one target per
>>>> language
>>>>>> type, or more detailed, one target per language/directory.
>>>>>
>>>>> So far, I just started with ede-simple-project, which I created
>> with
>>>> the
>>>>> command ede-new while visiting a Java file buried deep in that
> part
>>>> of
>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>> defining
>>>>> that ede-simple-project.  I also have run GNU Global in my project
>>>> root.
>>>>> What do I do now to enable completion, lookup, and
> cross-references
>>>> for
>>>>> symbols?
>>>>
>>>> Ah, good idea with the simple project.  I'd forgotten about that.
>>>>
>>>> If you look in cedet/common/cedet.info in the node:
>>>>
>>>> (cedet.info)Top::>   GNU Global
>>>>
>>>> It lists all the options for enabling GNU Global in a CEDET
> project.
>>>>
>>>>>> As for the symbol references, you can use any of the different
>>> tools
>>>>>> you
>>>>>> prefer, or none.  If you try it (once you have an EDE project
>>>>>> specifying
>>>>>> the root) with the find/grep solution and it is fast enough, then
>>>> you
>>>>>> can consider yourself done.
>>>>>
>>>>> I made these customizations:
>>>>>
>>>>> (require 'cedet)
>>>>> (global-ede-mode 1)
>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>> (setq ede-locate-setup-options
>>>>>          '(ede-locate-global
>>>>>            ede-locate-base))
>>>>>
>>>>> But when I invoke the command semantic-symref-symbol on some
> symbol
>>>> in a
>>>>> Java file, I get the message:
>>>>>
>>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>>>
>>>>> What does this mean?
>>>>
>>>>
>>>> That means that semantic-symref-filepattern-alist needs to be
>>>> customized.  If you have a good customization, I'll add it to the
>>>> default value.
>>>>
>>>> Probably something like:
>>>>
>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>> 	'(jde-mode "*.java"))
>>>>
>>>> I'll fix the error message to be more obvious.
>>>>
>>>> Of course, this also means that it failed to auto-detect the GNU
>>> Global
>>>> tags file at the root of your project.  Use  M-x
>>>> cedet-gnu-global-show-root to determine if the detection is
> working.
>>>> If
>>>> it fails, then there is something in the Global doc that might
> help,
>>>> since CEDET just calls global with "-pq" options.
>>>>
>>>>> Finally, must one use Global, idutils, locate, etc., to do symbol
>>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>>>
>>>> The symref tool relies on at least one external tool, but it can
> use
>>>> find/grep commands to do it, so the other tools are not required,
>> but
>>>> will instead provide better and faster results.
>>>>
>>>>    >What I
>>>>> mean is, I gather that semantic is parsing and caching the tags
>> for,
>>>>> say, the Java files that I visit.  Is it possible to have semantic
>>>> parse
>>>>
>>>> Semantic only parses the tags (like ctags) and not the contents.
>>>>
>>>>> ALL my Java source files ahead of time (a la Global, idutils,
>> ctags,
>>>>> etc.), then just use semanticdb to support completion, lookup, and
>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>>>> evangelize
>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
>>> more
>>>>> external tools I have to integrate (like finding Windows versions
>> of
>>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
> it
>>>>> simply be too much of a performance hit to ask semantic to do what
>>>>> Global et al are optimized to do very fast?
>>>>
>>>> Semantic parses it's own tags because tools like global and ctags
>>>> provide only "quickie" information, and take many short-cuts to do
>> so.
>>>> To do what CEDET does with tags, it needs to be much more careful.
>>>>
>>>> Semantic also already has trouble with really huge projects, and
>> Emacs
>>>> Lisp is just the wrong language to implement symbol cross-reference
>>>> database in do the shear size.
>>>>
>>>> Instead, things like Global do a pretty good job on references, so
> I
>>>> use
>>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>>>> double-check each "hit" with a real analysis to prove that the hit
>> is
>>>> really a reference to a given symbol, and not some side-effect of
>>>> polymorphism or other trick.
>>>>
>>>> Anyway, Global is probably your best bet unless find/grep is fast
>>>> enough
>>>> for you.
>>>>
>>>> Good Luck!
>>>> Eric
>>>>
>>>>
>>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>
>>
> -----------------------------------------------------------------------
>> -------
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Hi Eric,

Sorry for not including that, but yes, I did.  The command
cedet-gnu-global-show-root does indeed report the root directory that
contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
cedet-gnu-global-search, and then invoke that command while in a Java
file below my project root, it seems to work.  I.e., I define:

(defun foo ()
  (interactive)
  (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))

Where "getOpenReserves" is the tag I'm cross-referencing.  If I run the
command foo while in a .java file, I get a *CEDET Global* buffer with
the appropriate tags pulled from GTAGS.  Evidently, semantic-symref and
semantic-symref-global are not calling the cedet-gnu-global-search
function in the right way.

Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 3:03 PM
> To: David Ventimiglia
> Cc: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> Hi,
> 
> Did you you use the GNU global command  "gtags" to create the GLOBAL
> database for your code?  I don't remember if you mentioned doing that
> or
> not.  You need to create the GTAGS files before global will work on
> your
> code.
> 
> cedet-gnu-global-show-root
> 
> will tell you if it is detecting GLOBAL files associated with your
> directory or not.
> 
> Eric
> 
> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> > Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
or
> > nothing at all, and I'm afraid there still must be something
> fundamental
> > I'm misunderstanding.  I made customizations in stepwise fashion:
> >
> > Step 1:  Added to .emacs
> > (require 'cedet)
> > (semantic-load-enable-code-helpers)
> > (global-ede-mode 1)
> > Result:  semantic-symref works, but uses grep
> >
> > Step 2:  Added to .emacs
> > (require 'ede-locate)
> > (setq ede-locate-setup-options
> >        '(ede-locate-global
> >          ede-locate-base))
> > Result:  semantic-symref works, but uses grep
> >
> > Step 3:  Added to .emacs
> > (require 'semantic-symref-grep)
> > (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
"*.java"))
> > (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> "*.java"))
> > Result:  semantic-symref works, but uses grep
> >
> > Step 4:  Used ede-new to create a Simple project, which landed in
> > %HOME%/.ede/
> > Result:  semantic-symref fails, reporting "No references found".
> >
> > Here's what the file in %HOME%/.ede/ looks like, where the contents
> of
> > :directory and :file just refer to things in my particular project
> > directory tree:
> > ;; Object cc
> > ;; EDE Simple Project
> > (ede-simple-project "cc"
> >    :name "cc"
> >    :directory
> > "c:/dev/eng/cc/denali/active/core/app-
> cc/cc/src/com/guidewire/cc/domain/
> > financials/impl/"
> >    :file
> > "!drive_c!dev!eng!cc!denali!active!core!app-
> cc!cc!src!com!guidewire!cc!d
> > omain!financials!impl!ProjSimple.ede"
> >    :targets 'nil
> >    )
> >
> > I must be missing something, but I'm afraid I just can't see what it
> is.
> >
> > Best,
> > David
> >
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 1:26 PM
> >> To: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> If you use semantic-symref-data-debug-last-result it will show the
> >> object that contains the data, and it is named after the tool it
> uses,
> >> like grep or global.
> >>
> >> Eric
> >>
> >> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  I think it might be working for me.  At least, when
> I
> >> do
> >>> semantic-symref on a Java function in my project, I get a buffer
> > with
> >> a
> >>> list of references.  It's a little slow, however, and I'm
wondering
> >> if
> >>> it's falling back on Grep and not using my Global tags files.  The
> >>> command cedet-gnu-global-show-root does show the right project
> root,
> >>> however.
> >>>
> >>> Question:  is there a way to verify it's using Global and not
Grep?
> >>>
> >>> Thanks!
> >>> Best,
> >>> David
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>> To: David Ventimiglia
> >>>> Cc: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
> >> below.
> >>>>>
> >>>>>> The basic strategy is to get an EDE project pointing to the
root
> >> of
> >>>>> all
> >>>>>> your code.  I'm assuming all the languages you mentioned are in
> >> one
> >>>>> big
> >>>>>> mega-project.  That top level project then needs to know about
> > all
> >>>> the
> >>>>>> targets.  For simplicity sake, you could have one target per
> >>>> language
> >>>>>> type, or more detailed, one target per language/directory.
> >>>>>
> >>>>> So far, I just started with ede-simple-project, which I created
> >> with
> >>>> the
> >>>>> command ede-new while visiting a Java file buried deep in that
> > part
> >>>> of
> >>>>> our source-tree.  This put a file in my $HOME/.ede directory
> >>> defining
> >>>>> that ede-simple-project.  I also have run GNU Global in my
> project
> >>>> root.
> >>>>> What do I do now to enable completion, lookup, and
> > cross-references
> >>>> for
> >>>>> symbols?
> >>>>
> >>>> Ah, good idea with the simple project.  I'd forgotten about that.
> >>>>
> >>>> If you look in cedet/common/cedet.info in the node:
> >>>>
> >>>> (cedet.info)Top::>   GNU Global
> >>>>
> >>>> It lists all the options for enabling GNU Global in a CEDET
> > project.
> >>>>
> >>>>>> As for the symbol references, you can use any of the different
> >>> tools
> >>>>>> you
> >>>>>> prefer, or none.  If you try it (once you have an EDE project
> >>>>>> specifying
> >>>>>> the root) with the find/grep solution and it is fast enough,
> then
> >>>> you
> >>>>>> can consider yourself done.
> >>>>>
> >>>>> I made these customizations:
> >>>>>
> >>>>> (require 'cedet)
> >>>>> (global-ede-mode 1)
> >>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>> (setq ede-locate-setup-options
> >>>>>          '(ede-locate-global
> >>>>>            ede-locate-base))
> >>>>>
> >>>>> But when I invoke the command semantic-symref-symbol on some
> > symbol
> >>>> in a
> >>>>> Java file, I get the message:
> >>>>>
> >>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
> >>>>>
> >>>>> What does this mean?
> >>>>
> >>>>
> >>>> That means that semantic-symref-filepattern-alist needs to be
> >>>> customized.  If you have a good customization, I'll add it to the
> >>>> default value.
> >>>>
> >>>> Probably something like:
> >>>>
> >>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>> 	'(jde-mode "*.java"))
> >>>>
> >>>> I'll fix the error message to be more obvious.
> >>>>
> >>>> Of course, this also means that it failed to auto-detect the GNU
> >>> Global
> >>>> tags file at the root of your project.  Use  M-x
> >>>> cedet-gnu-global-show-root to determine if the detection is
> > working.
> >>>> If
> >>>> it fails, then there is something in the Global doc that might
> > help,
> >>>> since CEDET just calls global with "-pq" options.
> >>>>
> >>>>> Finally, must one use Global, idutils, locate, etc., to do
symbol
> >>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
> >>>>
> >>>> The symref tool relies on at least one external tool, but it can
> > use
> >>>> find/grep commands to do it, so the other tools are not required,
> >> but
> >>>> will instead provide better and faster results.
> >>>>
> >>>>    >What I
> >>>>> mean is, I gather that semantic is parsing and caching the tags
> >> for,
> >>>>> say, the Java files that I visit.  Is it possible to have
> semantic
> >>>> parse
> >>>>
> >>>> Semantic only parses the tags (like ctags) and not the contents.
> >>>>
> >>>>> ALL my Java source files ahead of time (a la Global, idutils,
> >> ctags,
> >>>>> etc.), then just use semanticdb to support completion, lookup,
> and
> >>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >>>> evangelize
> >>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
> >>> more
> >>>>> external tools I have to integrate (like finding Windows
versions
> >> of
> >>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
> > it
> >>>>> simply be too much of a performance hit to ask semantic to do
> what
> >>>>> Global et al are optimized to do very fast?
> >>>>
> >>>> Semantic parses it's own tags because tools like global and ctags
> >>>> provide only "quickie" information, and take many short-cuts to
do
> >> so.
> >>>> To do what CEDET does with tags, it needs to be much more
careful.
> >>>>
> >>>> Semantic also already has trouble with really huge projects, and
> >> Emacs
> >>>> Lisp is just the wrong language to implement symbol cross-
> reference
> >>>> database in do the shear size.
> >>>>
> >>>> Instead, things like Global do a pretty good job on references,
so
> > I
> >>>> use
> >>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
> >>>> double-check each "hit" with a real analysis to prove that the
hit
> >> is
> >>>> really a reference to a given symbol, and not some side-effect of
> >>>> polymorphism or other trick.
> >>>>
> >>>> Anyway, Global is probably your best bet unless find/grep is fast
> >>>> enough
> >>>> for you.
> >>>>
> >>>> Good Luck!
> >>>> Eric
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ---------
> >>> _______________________________________________
> >>> cedet-semantic mailing list
> >>> cedet-semantic@...
> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >>
> >>
> >
---------------------------------------------------------------------
> --
> >> -------
> >> _______________________________________________
> >> cedet-semantic mailing list
> >> cedet-semantic@...
> >> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >

Looking in semantic-symref, I see that the location of GPATH (a GNU 
Global tags file) needs to exist in the directory that is equivalent to 
what EDE returns as the root directory.

I think you can also set semantic-symref-tool to be 'global to turn off 
the auto-detect feature.  In that case, I don't think anything needs to 
match.

Eric

On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> Hi Eric,
>
> Sorry for not including that, but yes, I did.  The command
> cedet-gnu-global-show-root does indeed report the root directory that
> contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
> cedet-gnu-global-search, and then invoke that command while in a Java
> file below my project root, it seems to work.  I.e., I define:
>
> (defun foo ()
>    (interactive)
>    (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))
>
> Where "getOpenReserves" is the tag I'm cross-referencing.  If I run the
> command foo while in a .java file, I get a *CEDET Global* buffer with
> the appropriate tags pulled from GTAGS.  Evidently, semantic-symref and
> semantic-symref-global are not calling the cedet-gnu-global-search
> function in the right way.
>
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 3:03 PM
>> To: David Ventimiglia
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> Hi,
>>
>> Did you you use the GNU global command  "gtags" to create the GLOBAL
>> database for your code?  I don't remember if you mentioned doing that
>> or
>> not.  You need to create the GTAGS files before global will work on
>> your
>> code.
>>
>> cedet-gnu-global-show-root
>>
>> will tell you if it is detecting GLOBAL files associated with your
>> directory or not.
>>
>> Eric
>>
>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
>>> Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
> or
>>> nothing at all, and I'm afraid there still must be something
>> fundamental
>>> I'm misunderstanding.  I made customizations in stepwise fashion:
>>>
>>> Step 1:  Added to .emacs
>>> (require 'cedet)
>>> (semantic-load-enable-code-helpers)
>>> (global-ede-mode 1)
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 2:  Added to .emacs
>>> (require 'ede-locate)
>>> (setq ede-locate-setup-options
>>>         '(ede-locate-global
>>>           ede-locate-base))
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 3:  Added to .emacs
>>> (require 'semantic-symref-grep)
>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> "*.java"))
>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
>> "*.java"))
>>> Result:  semantic-symref works, but uses grep
>>>
>>> Step 4:  Used ede-new to create a Simple project, which landed in
>>> %HOME%/.ede/
>>> Result:  semantic-symref fails, reporting "No references found".
>>>
>>> Here's what the file in %HOME%/.ede/ looks like, where the contents
>> of
>>> :directory and :file just refer to things in my particular project
>>> directory tree:
>>> ;; Object cc
>>> ;; EDE Simple Project
>>> (ede-simple-project "cc"
>>>     :name "cc"
>>>     :directory
>>> "c:/dev/eng/cc/denali/active/core/app-
>> cc/cc/src/com/guidewire/cc/domain/
>>> financials/impl/"
>>>     :file
>>> "!drive_c!dev!eng!cc!denali!active!core!app-
>> cc!cc!src!com!guidewire!cc!d
>>> omain!financials!impl!ProjSimple.ede"
>>>     :targets 'nil
>>>     )
>>>
>>> I must be missing something, but I'm afraid I just can't see what it
>> is.
>>>
>>> Best,
>>> David
>>>
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Tuesday, May 04, 2010 1:26 PM
>>>> To: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> If you use semantic-symref-data-debug-last-result it will show the
>>>> object that contains the data, and it is named after the tool it
>> uses,
>>>> like grep or global.
>>>>
>>>> Eric
>>>>
>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>>>> Thanks, Eric.  I think it might be working for me.  At least, when
>> I
>>>> do
>>>>> semantic-symref on a Java function in my project, I get a buffer
>>> with
>>>> a
>>>>> list of references.  It's a little slow, however, and I'm
> wondering
>>>> if
>>>>> it's falling back on Grep and not using my Global tags files.  The
>>>>> command cedet-gnu-global-show-root does show the right project
>> root,
>>>>> however.
>>>>>
>>>>> Question:  is there a way to verify it's using Global and not
> Grep?
>>>>>
>>>>> Thanks!
>>>>> Best,
>>>>> David
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>>>> To: David Ventimiglia
>>>>>> Cc: cedet-semantic@...
>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>> JDEE
>>>>> user
>>>>>> for a (mostly) Java project
>>>>>>
>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
>>>> below.
>>>>>>>
>>>>>>>> The basic strategy is to get an EDE project pointing to the
> root
>>>> of
>>>>>>> all
>>>>>>>> your code.  I'm assuming all the languages you mentioned are in
>>>> one
>>>>>>> big
>>>>>>>> mega-project.  That top level project then needs to know about
>>> all
>>>>>> the
>>>>>>>> targets.  For simplicity sake, you could have one target per
>>>>>> language
>>>>>>>> type, or more detailed, one target per language/directory.
>>>>>>>
>>>>>>> So far, I just started with ede-simple-project, which I created
>>>> with
>>>>>> the
>>>>>>> command ede-new while visiting a Java file buried deep in that
>>> part
>>>>>> of
>>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>>>> defining
>>>>>>> that ede-simple-project.  I also have run GNU Global in my
>> project
>>>>>> root.
>>>>>>> What do I do now to enable completion, lookup, and
>>> cross-references
>>>>>> for
>>>>>>> symbols?
>>>>>>
>>>>>> Ah, good idea with the simple project.  I'd forgotten about that.
>>>>>>
>>>>>> If you look in cedet/common/cedet.info in the node:
>>>>>>
>>>>>> (cedet.info)Top::>    GNU Global
>>>>>>
>>>>>> It lists all the options for enabling GNU Global in a CEDET
>>> project.
>>>>>>
>>>>>>>> As for the symbol references, you can use any of the different
>>>>> tools
>>>>>>>> you
>>>>>>>> prefer, or none.  If you try it (once you have an EDE project
>>>>>>>> specifying
>>>>>>>> the root) with the find/grep solution and it is fast enough,
>> then
>>>>>> you
>>>>>>>> can consider yourself done.
>>>>>>>
>>>>>>> I made these customizations:
>>>>>>>
>>>>>>> (require 'cedet)
>>>>>>> (global-ede-mode 1)
>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>>>> (setq ede-locate-setup-options
>>>>>>>           '(ede-locate-global
>>>>>>>             ede-locate-base))
>>>>>>>
>>>>>>> But when I invoke the command semantic-symref-symbol on some
>>> symbol
>>>>>> in a
>>>>>>> Java file, I get the message:
>>>>>>>
>>>>>>> semantic-symref-tool-grep - Needs to be configured for jde-mode
>>>>>>>
>>>>>>> What does this mean?
>>>>>>
>>>>>>
>>>>>> That means that semantic-symref-filepattern-alist needs to be
>>>>>> customized.  If you have a good customization, I'll add it to the
>>>>>> default value.
>>>>>>
>>>>>> Probably something like:
>>>>>>
>>>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>>>> 	'(jde-mode "*.java"))
>>>>>>
>>>>>> I'll fix the error message to be more obvious.
>>>>>>
>>>>>> Of course, this also means that it failed to auto-detect the GNU
>>>>> Global
>>>>>> tags file at the root of your project.  Use  M-x
>>>>>> cedet-gnu-global-show-root to determine if the detection is
>>> working.
>>>>>> If
>>>>>> it fails, then there is something in the Global doc that might
>>> help,
>>>>>> since CEDET just calls global with "-pq" options.
>>>>>>
>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> symbol
>>>>>>> lookups?  Is it possible just to rely on the CEDET tools alone?
>>>>>>
>>>>>> The symref tool relies on at least one external tool, but it can
>>> use
>>>>>> find/grep commands to do it, so the other tools are not required,
>>>> but
>>>>>> will instead provide better and faster results.
>>>>>>
>>>>>>     >What I
>>>>>>> mean is, I gather that semantic is parsing and caching the tags
>>>> for,
>>>>>>> say, the Java files that I visit.  Is it possible to have
>> semantic
>>>>>> parse
>>>>>>
>>>>>> Semantic only parses the tags (like ctags) and not the contents.
>>>>>>
>>>>>>> ALL my Java source files ahead of time (a la Global, idutils,
>>>> ctags,
>>>>>>> etc.), then just use semanticdb to support completion, lookup,
>> and
>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>>>>>> evangelize
>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and the
>>>>> more
>>>>>>> external tools I have to integrate (like finding Windows
> versions
>>>> of
>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or, would
>>> it
>>>>>>> simply be too much of a performance hit to ask semantic to do
>> what
>>>>>>> Global et al are optimized to do very fast?
>>>>>>
>>>>>> Semantic parses it's own tags because tools like global and ctags
>>>>>> provide only "quickie" information, and take many short-cuts to
> do
>>>> so.
>>>>>> To do what CEDET does with tags, it needs to be much more
> careful.
>>>>>>
>>>>>> Semantic also already has trouble with really huge projects, and
>>>> Emacs
>>>>>> Lisp is just the wrong language to implement symbol cross-
>> reference
>>>>>> database in do the shear size.
>>>>>>
>>>>>> Instead, things like Global do a pretty good job on references,
> so
>>> I
>>>>>> use
>>>>>> those instead, and deal with the inaccuracy of it.  I'm hoping to
>>>>>> double-check each "hit" with a real analysis to prove that the
> hit
>>>> is
>>>>>> really a reference to a given symbol, and not some side-effect of
>>>>>> polymorphism or other trick.
>>>>>>
>>>>>> Anyway, Global is probably your best bet unless find/grep is fast
>>>>>> enough
>>>>>> for you.
>>>>>>
>>>>>> Good Luck!
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>> ---------
>>>>> _______________________________________________
>>>>> cedet-semantic mailing list
>>>>> cedet-semantic@...
>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>
>>>>
>>>>
>>>
> ---------------------------------------------------------------------
>> --
>>>> -------
>>>> _______________________________________________
>>>> cedet-semantic mailing list
>>>> cedet-semantic@...
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Great!  That worked!  I added this to java-mode-hook:

(lambda () (setq semantic-symref-tool 'global))

So, should I be setting this variable, or is there a way to get EDE to
return the proper root directory?  Very likely, I've not set up my EDE
project correctly.

Best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 4:41 PM
> To: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> Looking in semantic-symref, I see that the location of GPATH (a GNU
> Global tags file) needs to exist in the directory that is equivalent
to
> what EDE returns as the root directory.
> 
> I think you can also set semantic-symref-tool to be 'global to turn
off
> the auto-detect feature.  In that case, I don't think anything needs
to
> match.
> 
> Eric
> 
> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> > Hi Eric,
> >
> > Sorry for not including that, but yes, I did.  The command
> > cedet-gnu-global-show-root does indeed report the root directory
that
> > contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
> > cedet-gnu-global-search, and then invoke that command while in a
Java
> > file below my project root, it seems to work.  I.e., I define:
> >
> > (defun foo ()
> >    (interactive)
> >    (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))
> >
> > Where "getOpenReserves" is the tag I'm cross-referencing.  If I run
> the
> > command foo while in a .java file, I get a *CEDET Global* buffer
with
> > the appropriate tags pulled from GTAGS.  Evidently, semantic-symref
> and
> > semantic-symref-global are not calling the cedet-gnu-global-search
> > function in the right way.
> >
> > Best,
> > David
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 3:03 PM
> >> To: David Ventimiglia
> >> Cc: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> Hi,
> >>
> >> Did you you use the GNU global command  "gtags" to create the
GLOBAL
> >> database for your code?  I don't remember if you mentioned doing
> that
> >> or
> >> not.  You need to create the GTAGS files before global will work on
> >> your
> >> code.
> >>
> >> cedet-gnu-global-show-root
> >>
> >> will tell you if it is detecting GLOBAL files associated with your
> >> directory or not.
> >>
> >> Eric
> >>
> >> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> >>> Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
> > or
> >>> nothing at all, and I'm afraid there still must be something
> >> fundamental
> >>> I'm misunderstanding.  I made customizations in stepwise fashion:
> >>>
> >>> Step 1:  Added to .emacs
> >>> (require 'cedet)
> >>> (semantic-load-enable-code-helpers)
> >>> (global-ede-mode 1)
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 2:  Added to .emacs
> >>> (require 'ede-locate)
> >>> (setq ede-locate-setup-options
> >>>         '(ede-locate-global
> >>>           ede-locate-base))
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 3:  Added to .emacs
> >>> (require 'semantic-symref-grep)
> >>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> > "*.java"))
> >>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> >> "*.java"))
> >>> Result:  semantic-symref works, but uses grep
> >>>
> >>> Step 4:  Used ede-new to create a Simple project, which landed in
> >>> %HOME%/.ede/
> >>> Result:  semantic-symref fails, reporting "No references found".
> >>>
> >>> Here's what the file in %HOME%/.ede/ looks like, where the
contents
> >> of
> >>> :directory and :file just refer to things in my particular project
> >>> directory tree:
> >>> ;; Object cc
> >>> ;; EDE Simple Project
> >>> (ede-simple-project "cc"
> >>>     :name "cc"
> >>>     :directory
> >>> "c:/dev/eng/cc/denali/active/core/app-
> >> cc/cc/src/com/guidewire/cc/domain/
> >>> financials/impl/"
> >>>     :file
> >>> "!drive_c!dev!eng!cc!denali!active!core!app-
> >> cc!cc!src!com!guidewire!cc!d
> >>> omain!financials!impl!ProjSimple.ede"
> >>>     :targets 'nil
> >>>     )
> >>>
> >>> I must be missing something, but I'm afraid I just can't see what
> it
> >> is.
> >>>
> >>> Best,
> >>> David
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Tuesday, May 04, 2010 1:26 PM
> >>>> To: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> If you use semantic-symref-data-debug-last-result it will show
the
> >>>> object that contains the data, and it is named after the tool it
> >> uses,
> >>>> like grep or global.
> >>>>
> >>>> Eric
> >>>>
> >>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>>>> Thanks, Eric.  I think it might be working for me.  At least,
> when
> >> I
> >>>> do
> >>>>> semantic-symref on a Java function in my project, I get a buffer
> >>> with
> >>>> a
> >>>>> list of references.  It's a little slow, however, and I'm
> > wondering
> >>>> if
> >>>>> it's falling back on Grep and not using my Global tags files.
> The
> >>>>> command cedet-gnu-global-show-root does show the right project
> >> root,
> >>>>> however.
> >>>>>
> >>>>> Question:  is there a way to verify it's using Global and not
> > Grep?
> >>>>>
> >>>>> Thanks!
> >>>>> Best,
> >>>>> David
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>>>> To: David Ventimiglia
> >>>>>> Cc: cedet-semantic@...
> >>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >> JDEE
> >>>>> user
> >>>>>> for a (mostly) Java project
> >>>>>>
> >>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
> >>>> below.
> >>>>>>>
> >>>>>>>> The basic strategy is to get an EDE project pointing to the
> > root
> >>>> of
> >>>>>>> all
> >>>>>>>> your code.  I'm assuming all the languages you mentioned are
> in
> >>>> one
> >>>>>>> big
> >>>>>>>> mega-project.  That top level project then needs to know
about
> >>> all
> >>>>>> the
> >>>>>>>> targets.  For simplicity sake, you could have one target per
> >>>>>> language
> >>>>>>>> type, or more detailed, one target per language/directory.
> >>>>>>>
> >>>>>>> So far, I just started with ede-simple-project, which I
created
> >>>> with
> >>>>>> the
> >>>>>>> command ede-new while visiting a Java file buried deep in that
> >>> part
> >>>>>> of
> >>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
> >>>>> defining
> >>>>>>> that ede-simple-project.  I also have run GNU Global in my
> >> project
> >>>>>> root.
> >>>>>>> What do I do now to enable completion, lookup, and
> >>> cross-references
> >>>>>> for
> >>>>>>> symbols?
> >>>>>>
> >>>>>> Ah, good idea with the simple project.  I'd forgotten about
> that.
> >>>>>>
> >>>>>> If you look in cedet/common/cedet.info in the node:
> >>>>>>
> >>>>>> (cedet.info)Top::>    GNU Global
> >>>>>>
> >>>>>> It lists all the options for enabling GNU Global in a CEDET
> >>> project.
> >>>>>>
> >>>>>>>> As for the symbol references, you can use any of the
different
> >>>>> tools
> >>>>>>>> you
> >>>>>>>> prefer, or none.  If you try it (once you have an EDE project
> >>>>>>>> specifying
> >>>>>>>> the root) with the find/grep solution and it is fast enough,
> >> then
> >>>>>> you
> >>>>>>>> can consider yourself done.
> >>>>>>>
> >>>>>>> I made these customizations:
> >>>>>>>
> >>>>>>> (require 'cedet)
> >>>>>>> (global-ede-mode 1)
> >>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>>>> (setq ede-locate-setup-options
> >>>>>>>           '(ede-locate-global
> >>>>>>>             ede-locate-base))
> >>>>>>>
> >>>>>>> But when I invoke the command semantic-symref-symbol on some
> >>> symbol
> >>>>>> in a
> >>>>>>> Java file, I get the message:
> >>>>>>>
> >>>>>>> semantic-symref-tool-grep - Needs to be configured for
jde-mode
> >>>>>>>
> >>>>>>> What does this mean?
> >>>>>>
> >>>>>>
> >>>>>> That means that semantic-symref-filepattern-alist needs to be
> >>>>>> customized.  If you have a good customization, I'll add it to
> the
> >>>>>> default value.
> >>>>>>
> >>>>>> Probably something like:
> >>>>>>
> >>>>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>>>> 	'(jde-mode "*.java"))
> >>>>>>
> >>>>>> I'll fix the error message to be more obvious.
> >>>>>>
> >>>>>> Of course, this also means that it failed to auto-detect the
GNU
> >>>>> Global
> >>>>>> tags file at the root of your project.  Use  M-x
> >>>>>> cedet-gnu-global-show-root to determine if the detection is
> >>> working.
> >>>>>> If
> >>>>>> it fails, then there is something in the Global doc that might
> >>> help,
> >>>>>> since CEDET just calls global with "-pq" options.
> >>>>>>
> >>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> > symbol
> >>>>>>> lookups?  Is it possible just to rely on the CEDET tools
alone?
> >>>>>>
> >>>>>> The symref tool relies on at least one external tool, but it
can
> >>> use
> >>>>>> find/grep commands to do it, so the other tools are not
> required,
> >>>> but
> >>>>>> will instead provide better and faster results.
> >>>>>>
> >>>>>>     >What I
> >>>>>>> mean is, I gather that semantic is parsing and caching the
tags
> >>>> for,
> >>>>>>> say, the Java files that I visit.  Is it possible to have
> >> semantic
> >>>>>> parse
> >>>>>>
> >>>>>> Semantic only parses the tags (like ctags) and not the
contents.
> >>>>>>
> >>>>>>> ALL my Java source files ahead of time (a la Global, idutils,
> >>>> ctags,
> >>>>>>> etc.), then just use semanticdb to support completion, lookup,
> >> and
> >>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
> >>>>>> evangelize
> >>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and
> the
> >>>>> more
> >>>>>>> external tools I have to integrate (like finding Windows
> > versions
> >>>> of
> >>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
> would
> >>> it
> >>>>>>> simply be too much of a performance hit to ask semantic to do
> >> what
> >>>>>>> Global et al are optimized to do very fast?
> >>>>>>
> >>>>>> Semantic parses it's own tags because tools like global and
> ctags
> >>>>>> provide only "quickie" information, and take many short-cuts to
> > do
> >>>> so.
> >>>>>> To do what CEDET does with tags, it needs to be much more
> > careful.
> >>>>>>
> >>>>>> Semantic also already has trouble with really huge projects,
and
> >>>> Emacs
> >>>>>> Lisp is just the wrong language to implement symbol cross-
> >> reference
> >>>>>> database in do the shear size.
> >>>>>>
> >>>>>> Instead, things like Global do a pretty good job on references,
> > so
> >>> I
> >>>>>> use
> >>>>>> those instead, and deal with the inaccuracy of it.  I'm hoping
> to
> >>>>>> double-check each "hit" with a real analysis to prove that the
> > hit
> >>>> is
> >>>>>> really a reference to a given symbol, and not some side-effect
> of
> >>>>>> polymorphism or other trick.
> >>>>>>
> >>>>>> Anyway, Global is probably your best bet unless find/grep is
> fast
> >>>>>> enough
> >>>>>> for you.
> >>>>>>
> >>>>>> Good Luck!
> >>>>>> Eric
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>> ---------
> >>>>> _______________________________________________
> >>>>> cedet-semantic mailing list
> >>>>> cedet-semantic@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>
> >>>>
> >>>>
> >>>
> >
---------------------------------------------------------------------
> >> --
> >>>> -------
> >>>> _______________________________________________
> >>>> cedet-semantic mailing list
> >>>> cedet-semantic@...
> >>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ---------
> >>> _______________________________________________
> >>> cedet-semantic mailing list
> >>> cedet-semantic@...
> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> 
>
-----------------------------------------------------------------------
> -------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

I think all you need to do is make sure that the root of your EDE 
project is the same location as the location of your GPATH file, or 
where you ran gtags from.

If you work on lots of different projects with different tagging 
schemes, then you want the autodetect feature.  If you always work on 
the same thing, then it doesn't really matter.

Eric

On 05/04/2010 07:52 PM, David Ventimiglia wrote:
> Great!  That worked!  I added this to java-mode-hook:
>
> (lambda () (setq semantic-symref-tool 'global))
>
> So, should I be setting this variable, or is there a way to get EDE to
> return the proper root directory?  Very likely, I've not set up my EDE
> project correctly.
>
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 4:41 PM
>> To: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> Looking in semantic-symref, I see that the location of GPATH (a GNU
>> Global tags file) needs to exist in the directory that is equivalent
> to
>> what EDE returns as the root directory.
>>
>> I think you can also set semantic-symref-tool to be 'global to turn
> off
>> the auto-detect feature.  In that case, I don't think anything needs
> to
>> match.
>>
>> Eric
>>
>> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
>>> Hi Eric,
>>>
>>> Sorry for not including that, but yes, I did.  The command
>>> cedet-gnu-global-show-root does indeed report the root directory
> that
>>> contains GTAGS, GRTAGS, etc.  If I cobble together a command to call
>>> cedet-gnu-global-search, and then invoke that command while in a
> Java
>>> file below my project root, it seems to work.  I.e., I define:
>>>
>>> (defun foo ()
>>>     (interactive)
>>>     (cedet-gnu-global-search "getOpenReserves" 'string nil 'project))
>>>
>>> Where "getOpenReserves" is the tag I'm cross-referencing.  If I run
>> the
>>> command foo while in a .java file, I get a *CEDET Global* buffer
> with
>>> the appropriate tags pulled from GTAGS.  Evidently, semantic-symref
>> and
>>> semantic-symref-global are not calling the cedet-gnu-global-search
>>> function in the right way.
>>>
>>> Best,
>>> David
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Tuesday, May 04, 2010 3:03 PM
>>>> To: David Ventimiglia
>>>> Cc: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> Hi,
>>>>
>>>> Did you you use the GNU global command  "gtags" to create the
> GLOBAL
>>>> database for your code?  I don't remember if you mentioned doing
>> that
>>>> or
>>>> not.  You need to create the GTAGS files before global will work on
>>>> your
>>>> code.
>>>>
>>>> cedet-gnu-global-show-root
>>>>
>>>> will tell you if it is detecting GLOBAL files associated with your
>>>> directory or not.
>>>>
>>>> Eric
>>>>
>>>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
>>>>> Thanks, Eric.  Unfortunately, it resolutely insists on using grep,
>>> or
>>>>> nothing at all, and I'm afraid there still must be something
>>>> fundamental
>>>>> I'm misunderstanding.  I made customizations in stepwise fashion:
>>>>>
>>>>> Step 1:  Added to .emacs
>>>>> (require 'cedet)
>>>>> (semantic-load-enable-code-helpers)
>>>>> (global-ede-mode 1)
>>>>> Result:  semantic-symref works, but uses grep
>>>>>
>>>>> Step 2:  Added to .emacs
>>>>> (require 'ede-locate)
>>>>> (setq ede-locate-setup-options
>>>>>          '(ede-locate-global
>>>>>            ede-locate-base))
>>>>> Result:  semantic-symref works, but uses grep
>>>>>
>>>>> Step 3:  Added to .emacs
>>>>> (require 'semantic-symref-grep)
>>>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
>>> "*.java"))
>>>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
>>>> "*.java"))
>>>>> Result:  semantic-symref works, but uses grep
>>>>>
>>>>> Step 4:  Used ede-new to create a Simple project, which landed in
>>>>> %HOME%/.ede/
>>>>> Result:  semantic-symref fails, reporting "No references found".
>>>>>
>>>>> Here's what the file in %HOME%/.ede/ looks like, where the
> contents
>>>> of
>>>>> :directory and :file just refer to things in my particular project
>>>>> directory tree:
>>>>> ;; Object cc
>>>>> ;; EDE Simple Project
>>>>> (ede-simple-project "cc"
>>>>>      :name "cc"
>>>>>      :directory
>>>>> "c:/dev/eng/cc/denali/active/core/app-
>>>> cc/cc/src/com/guidewire/cc/domain/
>>>>> financials/impl/"
>>>>>      :file
>>>>> "!drive_c!dev!eng!cc!denali!active!core!app-
>>>> cc!cc!src!com!guidewire!cc!d
>>>>> omain!financials!impl!ProjSimple.ede"
>>>>>      :targets 'nil
>>>>>      )
>>>>>
>>>>> I must be missing something, but I'm afraid I just can't see what
>> it
>>>> is.
>>>>>
>>>>> Best,
>>>>> David
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>> Sent: Tuesday, May 04, 2010 1:26 PM
>>>>>> To: cedet-semantic@...
>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>> JDEE
>>>>> user
>>>>>> for a (mostly) Java project
>>>>>>
>>>>>> If you use semantic-symref-data-debug-last-result it will show
> the
>>>>>> object that contains the data, and it is named after the tool it
>>>> uses,
>>>>>> like grep or global.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>>>>>> Thanks, Eric.  I think it might be working for me.  At least,
>> when
>>>> I
>>>>>> do
>>>>>>> semantic-symref on a Java function in my project, I get a buffer
>>>>> with
>>>>>> a
>>>>>>> list of references.  It's a little slow, however, and I'm
>>> wondering
>>>>>> if
>>>>>>> it's falling back on Grep and not using my Global tags files.
>> The
>>>>>>> command cedet-gnu-global-show-root does show the right project
>>>> root,
>>>>>>> however.
>>>>>>>
>>>>>>> Question:  is there a way to verify it's using Global and not
>>> Grep?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Best,
>>>>>>> David
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>>>>>> To: David Ventimiglia
>>>>>>>> Cc: cedet-semantic@...
>>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>>>> JDEE
>>>>>>> user
>>>>>>>> for a (mostly) Java project
>>>>>>>>
>>>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced in
>>>>>> below.
>>>>>>>>>
>>>>>>>>>> The basic strategy is to get an EDE project pointing to the
>>> root
>>>>>> of
>>>>>>>>> all
>>>>>>>>>> your code.  I'm assuming all the languages you mentioned are
>> in
>>>>>> one
>>>>>>>>> big
>>>>>>>>>> mega-project.  That top level project then needs to know
> about
>>>>> all
>>>>>>>> the
>>>>>>>>>> targets.  For simplicity sake, you could have one target per
>>>>>>>> language
>>>>>>>>>> type, or more detailed, one target per language/directory.
>>>>>>>>>
>>>>>>>>> So far, I just started with ede-simple-project, which I
> created
>>>>>> with
>>>>>>>> the
>>>>>>>>> command ede-new while visiting a Java file buried deep in that
>>>>> part
>>>>>>>> of
>>>>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>>>>>> defining
>>>>>>>>> that ede-simple-project.  I also have run GNU Global in my
>>>> project
>>>>>>>> root.
>>>>>>>>> What do I do now to enable completion, lookup, and
>>>>> cross-references
>>>>>>>> for
>>>>>>>>> symbols?
>>>>>>>>
>>>>>>>> Ah, good idea with the simple project.  I'd forgotten about
>> that.
>>>>>>>>
>>>>>>>> If you look in cedet/common/cedet.info in the node:
>>>>>>>>
>>>>>>>> (cedet.info)Top::>     GNU Global
>>>>>>>>
>>>>>>>> It lists all the options for enabling GNU Global in a CEDET
>>>>> project.
>>>>>>>>
>>>>>>>>>> As for the symbol references, you can use any of the
> different
>>>>>>> tools
>>>>>>>>>> you
>>>>>>>>>> prefer, or none.  If you try it (once you have an EDE project
>>>>>>>>>> specifying
>>>>>>>>>> the root) with the find/grep solution and it is fast enough,
>>>> then
>>>>>>>> you
>>>>>>>>>> can consider yourself done.
>>>>>>>>>
>>>>>>>>> I made these customizations:
>>>>>>>>>
>>>>>>>>> (require 'cedet)
>>>>>>>>> (global-ede-mode 1)
>>>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>>>>>> (setq ede-locate-setup-options
>>>>>>>>>            '(ede-locate-global
>>>>>>>>>              ede-locate-base))
>>>>>>>>>
>>>>>>>>> But when I invoke the command semantic-symref-symbol on some
>>>>> symbol
>>>>>>>> in a
>>>>>>>>> Java file, I get the message:
>>>>>>>>>
>>>>>>>>> semantic-symref-tool-grep - Needs to be configured for
> jde-mode
>>>>>>>>>
>>>>>>>>> What does this mean?
>>>>>>>>
>>>>>>>>
>>>>>>>> That means that semantic-symref-filepattern-alist needs to be
>>>>>>>> customized.  If you have a good customization, I'll add it to
>> the
>>>>>>>> default value.
>>>>>>>>
>>>>>>>> Probably something like:
>>>>>>>>
>>>>>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>>>>>> 	'(jde-mode "*.java"))
>>>>>>>>
>>>>>>>> I'll fix the error message to be more obvious.
>>>>>>>>
>>>>>>>> Of course, this also means that it failed to auto-detect the
> GNU
>>>>>>> Global
>>>>>>>> tags file at the root of your project.  Use  M-x
>>>>>>>> cedet-gnu-global-show-root to determine if the detection is
>>>>> working.
>>>>>>>> If
>>>>>>>> it fails, then there is something in the Global doc that might
>>>>> help,
>>>>>>>> since CEDET just calls global with "-pq" options.
>>>>>>>>
>>>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
>>> symbol
>>>>>>>>> lookups?  Is it possible just to rely on the CEDET tools
> alone?
>>>>>>>>
>>>>>>>> The symref tool relies on at least one external tool, but it
> can
>>>>> use
>>>>>>>> find/grep commands to do it, so the other tools are not
>> required,
>>>>>> but
>>>>>>>> will instead provide better and faster results.
>>>>>>>>
>>>>>>>>      >What I
>>>>>>>>> mean is, I gather that semantic is parsing and caching the
> tags
>>>>>> for,
>>>>>>>>> say, the Java files that I visit.  Is it possible to have
>>>> semantic
>>>>>>>> parse
>>>>>>>>
>>>>>>>> Semantic only parses the tags (like ctags) and not the
> contents.
>>>>>>>>
>>>>>>>>> ALL my Java source files ahead of time (a la Global, idutils,
>>>>>> ctags,
>>>>>>>>> etc.), then just use semanticdb to support completion, lookup,
>>>> and
>>>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying to
>>>>>>>> evangelize
>>>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and
>> the
>>>>>>> more
>>>>>>>>> external tools I have to integrate (like finding Windows
>>> versions
>>>>>> of
>>>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
>> would
>>>>> it
>>>>>>>>> simply be too much of a performance hit to ask semantic to do
>>>> what
>>>>>>>>> Global et al are optimized to do very fast?
>>>>>>>>
>>>>>>>> Semantic parses it's own tags because tools like global and
>> ctags
>>>>>>>> provide only "quickie" information, and take many short-cuts to
>>> do
>>>>>> so.
>>>>>>>> To do what CEDET does with tags, it needs to be much more
>>> careful.
>>>>>>>>
>>>>>>>> Semantic also already has trouble with really huge projects,
> and
>>>>>> Emacs
>>>>>>>> Lisp is just the wrong language to implement symbol cross-
>>>> reference
>>>>>>>> database in do the shear size.
>>>>>>>>
>>>>>>>> Instead, things like Global do a pretty good job on references,
>>> so
>>>>> I
>>>>>>>> use
>>>>>>>> those instead, and deal with the inaccuracy of it.  I'm hoping
>> to
>>>>>>>> double-check each "hit" with a real analysis to prove that the
>>> hit
>>>>>> is
>>>>>>>> really a reference to a given symbol, and not some side-effect
>> of
>>>>>>>> polymorphism or other trick.
>>>>>>>>
>>>>>>>> Anyway, Global is probably your best bet unless find/grep is
>> fast
>>>>>>>> enough
>>>>>>>> for you.
>>>>>>>>
>>>>>>>> Good Luck!
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>>>> ---------
>>>>>>> _______________________________________________
>>>>>>> cedet-semantic mailing list
>>>>>>> cedet-semantic@...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>> --
>>>>>> -------
>>>>>> _______________________________________________
>>>>>> cedet-semantic mailing list
>>>>>> cedet-semantic@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>> ---------
>>>>> _______________________________________________
>>>>> cedet-semantic mailing list
>>>>> cedet-semantic@...
>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>>
>>
> -----------------------------------------------------------------------
>> -------
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Yes, but how do I make sure that the root of my EDE project is the same
location of my GPATH file?  I invoked ede-new from a Java file deep in
my source tree, so that the file in %HOME%/.ede has a long name with the
fully-qualified path to that Java file embedded in the name (with bangs
in place of the path separator), and inside that file it invokes
ede-simple-project with the keyword argument :directory set to the
directory containing that file, which again is deep into my source tree.
Does that mean my EDE root is set to that subdirectory?  That would be a
problem, because that's not where my GPATH file is.  GPATH is in the
true root of my project, which is like 5 directories up.  Should I
hand-edit the project file?  I tried that, setting :directory to the
actual root of my project (the directory containing GPATH), but still no
dice.  

Either way, it appears not to be finding and/or reading the project file
correctly, since running (semantic-symref-detect-symref-tool) returns
grep.  (ede-toplevel) returns nil, I guess because
ede-directory-get-open-project and ede-directory-project-p return nil
for default-directory.  

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Tuesday, May 04, 2010 5:51 PM
> To: David Ventimiglia
> Cc: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> I think all you need to do is make sure that the root of your EDE
> project is the same location as the location of your GPATH file, or
> where you ran gtags from.
> 
> If you work on lots of different projects with different tagging
> schemes, then you want the autodetect feature.  If you always work on
> the same thing, then it doesn't really matter.
> 
> Eric
> 
> On 05/04/2010 07:52 PM, David Ventimiglia wrote:
> > Great!  That worked!  I added this to java-mode-hook:
> >
> > (lambda () (setq semantic-symref-tool 'global))
> >
> > So, should I be setting this variable, or is there a way to get EDE
> to
> > return the proper root directory?  Very likely, I've not set up my
> EDE
> > project correctly.
> >
> > Best,
> > David
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 4:41 PM
> >> To: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> Looking in semantic-symref, I see that the location of GPATH (a GNU
> >> Global tags file) needs to exist in the directory that is
equivalent
> > to
> >> what EDE returns as the root directory.
> >>
> >> I think you can also set semantic-symref-tool to be 'global to turn
> > off
> >> the auto-detect feature.  In that case, I don't think anything
needs
> > to
> >> match.
> >>
> >> Eric
> >>
> >> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> >>> Hi Eric,
> >>>
> >>> Sorry for not including that, but yes, I did.  The command
> >>> cedet-gnu-global-show-root does indeed report the root directory
> > that
> >>> contains GTAGS, GRTAGS, etc.  If I cobble together a command to
> call
> >>> cedet-gnu-global-search, and then invoke that command while in a
> > Java
> >>> file below my project root, it seems to work.  I.e., I define:
> >>>
> >>> (defun foo ()
> >>>     (interactive)
> >>>     (cedet-gnu-global-search "getOpenReserves" 'string nil
> 'project))
> >>>
> >>> Where "getOpenReserves" is the tag I'm cross-referencing.  If I
run
> >> the
> >>> command foo while in a .java file, I get a *CEDET Global* buffer
> > with
> >>> the appropriate tags pulled from GTAGS.  Evidently,
semantic-symref
> >> and
> >>> semantic-symref-global are not calling the cedet-gnu-global-search
> >>> function in the right way.
> >>>
> >>> Best,
> >>> David
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Tuesday, May 04, 2010 3:03 PM
> >>>> To: David Ventimiglia
> >>>> Cc: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> Hi,
> >>>>
> >>>> Did you you use the GNU global command  "gtags" to create the
> > GLOBAL
> >>>> database for your code?  I don't remember if you mentioned doing
> >> that
> >>>> or
> >>>> not.  You need to create the GTAGS files before global will work
> on
> >>>> your
> >>>> code.
> >>>>
> >>>> cedet-gnu-global-show-root
> >>>>
> >>>> will tell you if it is detecting GLOBAL files associated with
your
> >>>> directory or not.
> >>>>
> >>>> Eric
> >>>>
> >>>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> >>>>> Thanks, Eric.  Unfortunately, it resolutely insists on using
> grep,
> >>> or
> >>>>> nothing at all, and I'm afraid there still must be something
> >>>> fundamental
> >>>>> I'm misunderstanding.  I made customizations in stepwise
fashion:
> >>>>>
> >>>>> Step 1:  Added to .emacs
> >>>>> (require 'cedet)
> >>>>> (semantic-load-enable-code-helpers)
> >>>>> (global-ede-mode 1)
> >>>>> Result:  semantic-symref works, but uses grep
> >>>>>
> >>>>> Step 2:  Added to .emacs
> >>>>> (require 'ede-locate)
> >>>>> (setq ede-locate-setup-options
> >>>>>          '(ede-locate-global
> >>>>>            ede-locate-base))
> >>>>> Result:  semantic-symref works, but uses grep
> >>>>>
> >>>>> Step 3:  Added to .emacs
> >>>>> (require 'semantic-symref-grep)
> >>>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> >>> "*.java"))
> >>>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> >>>> "*.java"))
> >>>>> Result:  semantic-symref works, but uses grep
> >>>>>
> >>>>> Step 4:  Used ede-new to create a Simple project, which landed
in
> >>>>> %HOME%/.ede/
> >>>>> Result:  semantic-symref fails, reporting "No references found".
> >>>>>
> >>>>> Here's what the file in %HOME%/.ede/ looks like, where the
> > contents
> >>>> of
> >>>>> :directory and :file just refer to things in my particular
> project
> >>>>> directory tree:
> >>>>> ;; Object cc
> >>>>> ;; EDE Simple Project
> >>>>> (ede-simple-project "cc"
> >>>>>      :name "cc"
> >>>>>      :directory
> >>>>> "c:/dev/eng/cc/denali/active/core/app-
> >>>> cc/cc/src/com/guidewire/cc/domain/
> >>>>> financials/impl/"
> >>>>>      :file
> >>>>> "!drive_c!dev!eng!cc!denali!active!core!app-
> >>>> cc!cc!src!com!guidewire!cc!d
> >>>>> omain!financials!impl!ProjSimple.ede"
> >>>>>      :targets 'nil
> >>>>>      )
> >>>>>
> >>>>> I must be missing something, but I'm afraid I just can't see
what
> >> it
> >>>> is.
> >>>>>
> >>>>> Best,
> >>>>> David
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>> Sent: Tuesday, May 04, 2010 1:26 PM
> >>>>>> To: cedet-semantic@...
> >>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >> JDEE
> >>>>> user
> >>>>>> for a (mostly) Java project
> >>>>>>
> >>>>>> If you use semantic-symref-data-debug-last-result it will show
> > the
> >>>>>> object that contains the data, and it is named after the tool
it
> >>>> uses,
> >>>>>> like grep or global.
> >>>>>>
> >>>>>> Eric
> >>>>>>
> >>>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>>>>>> Thanks, Eric.  I think it might be working for me.  At least,
> >> when
> >>>> I
> >>>>>> do
> >>>>>>> semantic-symref on a Java function in my project, I get a
> buffer
> >>>>> with
> >>>>>> a
> >>>>>>> list of references.  It's a little slow, however, and I'm
> >>> wondering
> >>>>>> if
> >>>>>>> it's falling back on Grep and not using my Global tags files.
> >> The
> >>>>>>> command cedet-gnu-global-show-root does show the right project
> >>>> root,
> >>>>>>> however.
> >>>>>>>
> >>>>>>> Question:  is there a way to verify it's using Global and not
> >>> Grep?
> >>>>>>>
> >>>>>>> Thanks!
> >>>>>>> Best,
> >>>>>>> David
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>>>>>> To: David Ventimiglia
> >>>>>>>> Cc: cedet-semantic@...
> >>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >>>> JDEE
> >>>>>>> user
> >>>>>>>> for a (mostly) Java project
> >>>>>>>>
> >>>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced
in
> >>>>>> below.
> >>>>>>>>>
> >>>>>>>>>> The basic strategy is to get an EDE project pointing to the
> >>> root
> >>>>>> of
> >>>>>>>>> all
> >>>>>>>>>> your code.  I'm assuming all the languages you mentioned
are
> >> in
> >>>>>> one
> >>>>>>>>> big
> >>>>>>>>>> mega-project.  That top level project then needs to know
> > about
> >>>>> all
> >>>>>>>> the
> >>>>>>>>>> targets.  For simplicity sake, you could have one target
per
> >>>>>>>> language
> >>>>>>>>>> type, or more detailed, one target per language/directory.
> >>>>>>>>>
> >>>>>>>>> So far, I just started with ede-simple-project, which I
> > created
> >>>>>> with
> >>>>>>>> the
> >>>>>>>>> command ede-new while visiting a Java file buried deep in
> that
> >>>>> part
> >>>>>>>> of
> >>>>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
> >>>>>>> defining
> >>>>>>>>> that ede-simple-project.  I also have run GNU Global in my
> >>>> project
> >>>>>>>> root.
> >>>>>>>>> What do I do now to enable completion, lookup, and
> >>>>> cross-references
> >>>>>>>> for
> >>>>>>>>> symbols?
> >>>>>>>>
> >>>>>>>> Ah, good idea with the simple project.  I'd forgotten about
> >> that.
> >>>>>>>>
> >>>>>>>> If you look in cedet/common/cedet.info in the node:
> >>>>>>>>
> >>>>>>>> (cedet.info)Top::>     GNU Global
> >>>>>>>>
> >>>>>>>> It lists all the options for enabling GNU Global in a CEDET
> >>>>> project.
> >>>>>>>>
> >>>>>>>>>> As for the symbol references, you can use any of the
> > different
> >>>>>>> tools
> >>>>>>>>>> you
> >>>>>>>>>> prefer, or none.  If you try it (once you have an EDE
> project
> >>>>>>>>>> specifying
> >>>>>>>>>> the root) with the find/grep solution and it is fast
enough,
> >>>> then
> >>>>>>>> you
> >>>>>>>>>> can consider yourself done.
> >>>>>>>>>
> >>>>>>>>> I made these customizations:
> >>>>>>>>>
> >>>>>>>>> (require 'cedet)
> >>>>>>>>> (global-ede-mode 1)
> >>>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>>>>>> (setq ede-locate-setup-options
> >>>>>>>>>            '(ede-locate-global
> >>>>>>>>>              ede-locate-base))
> >>>>>>>>>
> >>>>>>>>> But when I invoke the command semantic-symref-symbol on some
> >>>>> symbol
> >>>>>>>> in a
> >>>>>>>>> Java file, I get the message:
> >>>>>>>>>
> >>>>>>>>> semantic-symref-tool-grep - Needs to be configured for
> > jde-mode
> >>>>>>>>>
> >>>>>>>>> What does this mean?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> That means that semantic-symref-filepattern-alist needs to be
> >>>>>>>> customized.  If you have a good customization, I'll add it to
> >> the
> >>>>>>>> default value.
> >>>>>>>>
> >>>>>>>> Probably something like:
> >>>>>>>>
> >>>>>>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>>>>>> 	'(jde-mode "*.java"))
> >>>>>>>>
> >>>>>>>> I'll fix the error message to be more obvious.
> >>>>>>>>
> >>>>>>>> Of course, this also means that it failed to auto-detect the
> > GNU
> >>>>>>> Global
> >>>>>>>> tags file at the root of your project.  Use  M-x
> >>>>>>>> cedet-gnu-global-show-root to determine if the detection is
> >>>>> working.
> >>>>>>>> If
> >>>>>>>> it fails, then there is something in the Global doc that
might
> >>>>> help,
> >>>>>>>> since CEDET just calls global with "-pq" options.
> >>>>>>>>
> >>>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> >>> symbol
> >>>>>>>>> lookups?  Is it possible just to rely on the CEDET tools
> > alone?
> >>>>>>>>
> >>>>>>>> The symref tool relies on at least one external tool, but it
> > can
> >>>>> use
> >>>>>>>> find/grep commands to do it, so the other tools are not
> >> required,
> >>>>>> but
> >>>>>>>> will instead provide better and faster results.
> >>>>>>>>
> >>>>>>>>      >What I
> >>>>>>>>> mean is, I gather that semantic is parsing and caching the
> > tags
> >>>>>> for,
> >>>>>>>>> say, the Java files that I visit.  Is it possible to have
> >>>> semantic
> >>>>>>>> parse
> >>>>>>>>
> >>>>>>>> Semantic only parses the tags (like ctags) and not the
> > contents.
> >>>>>>>>
> >>>>>>>>> ALL my Java source files ahead of time (a la Global,
idutils,
> >>>>>> ctags,
> >>>>>>>>> etc.), then just use semanticdb to support completion,
> lookup,
> >>>> and
> >>>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying
to
> >>>>>>>> evangelize
> >>>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and
> >> the
> >>>>>>> more
> >>>>>>>>> external tools I have to integrate (like finding Windows
> >>> versions
> >>>>>> of
> >>>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
> >> would
> >>>>> it
> >>>>>>>>> simply be too much of a performance hit to ask semantic to
do
> >>>> what
> >>>>>>>>> Global et al are optimized to do very fast?
> >>>>>>>>
> >>>>>>>> Semantic parses it's own tags because tools like global and
> >> ctags
> >>>>>>>> provide only "quickie" information, and take many short-cuts
> to
> >>> do
> >>>>>> so.
> >>>>>>>> To do what CEDET does with tags, it needs to be much more
> >>> careful.
> >>>>>>>>
> >>>>>>>> Semantic also already has trouble with really huge projects,
> > and
> >>>>>> Emacs
> >>>>>>>> Lisp is just the wrong language to implement symbol cross-
> >>>> reference
> >>>>>>>> database in do the shear size.
> >>>>>>>>
> >>>>>>>> Instead, things like Global do a pretty good job on
> references,
> >>> so
> >>>>> I
> >>>>>>>> use
> >>>>>>>> those instead, and deal with the inaccuracy of it.  I'm
hoping
> >> to
> >>>>>>>> double-check each "hit" with a real analysis to prove that
the
> >>> hit
> >>>>>> is
> >>>>>>>> really a reference to a given symbol, and not some
side-effect
> >> of
> >>>>>>>> polymorphism or other trick.
> >>>>>>>>
> >>>>>>>> Anyway, Global is probably your best bet unless find/grep is
> >> fast
> >>>>>>>> enough
> >>>>>>>> for you.
> >>>>>>>>
> >>>>>>>> Good Luck!
> >>>>>>>> Eric
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>>>> ---------
> >>>>>>> _______________________________________________
> >>>>>>> cedet-semantic mailing list
> >>>>>>> cedet-semantic@...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>> --
> >>>>>> -------
> >>>>>> _______________________________________________
> >>>>>> cedet-semantic mailing list
> >>>>>> cedet-semantic@...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>> ---------
> >>>>> _______________________________________________
> >>>>> cedet-semantic mailing list
> >>>>> cedet-semantic@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>
> >>>
> >>>
> >
---------------------------------------------------------------------
> >> ---------
> >>> _______________________________________________
> >>> cedet-semantic mailing list
> >>> cedet-semantic@...
> >>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >>
> >>
> >
---------------------------------------------------------------------
> --
> >> -------
> >> _______________________________________________
> >> cedet-semantic mailing list
> >> cedet-semantic@...
> >> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >

Well, it looks like the simple project type isn't working.  I ran a 
quick interactive test for simple projects and it seems to work for me 
in terms of getting (ede-toplevel) to return the correct project type.

Do you use automounters or other unixy things where /home/project might 
also be seen as /automout/home/project or something like that?

I think the next thing to do is visit ede-simple.el, and use edebug on 
ede-simple-projectfile-for-dir (by putting the cursor in there and 
typing M-x edebug-defun) and then visit a file in your project.  The 
translation from dir to project can then be stepped through using SPC to 
see what is going on.

Eric

On 05/05/2010 12:31 AM, David Ventimiglia wrote:
> Yes, but how do I make sure that the root of my EDE project is the same
> location of my GPATH file?  I invoked ede-new from a Java file deep in
> my source tree, so that the file in %HOME%/.ede has a long name with the
> fully-qualified path to that Java file embedded in the name (with bangs
> in place of the path separator), and inside that file it invokes
> ede-simple-project with the keyword argument :directory set to the
> directory containing that file, which again is deep into my source tree.
> Does that mean my EDE root is set to that subdirectory?  That would be a
> problem, because that's not where my GPATH file is.  GPATH is in the
> true root of my project, which is like 5 directories up.  Should I
> hand-edit the project file?  I tried that, setting :directory to the
> actual root of my project (the directory containing GPATH), but still no
> dice.
>
> Either way, it appears not to be finding and/or reading the project file
> correctly, since running (semantic-symref-detect-symref-tool) returns
> grep.  (ede-toplevel) returns nil, I guess because
> ede-directory-get-open-project and ede-directory-project-p return nil
> for default-directory.
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Tuesday, May 04, 2010 5:51 PM
>> To: David Ventimiglia
>> Cc: cedet-semantic@...
>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> user
>> for a (mostly) Java project
>>
>> I think all you need to do is make sure that the root of your EDE
>> project is the same location as the location of your GPATH file, or
>> where you ran gtags from.
>>
>> If you work on lots of different projects with different tagging
>> schemes, then you want the autodetect feature.  If you always work on
>> the same thing, then it doesn't really matter.
>>
>> Eric
>>
>> On 05/04/2010 07:52 PM, David Ventimiglia wrote:
>>> Great!  That worked!  I added this to java-mode-hook:
>>>
>>> (lambda () (setq semantic-symref-tool 'global))
>>>
>>> So, should I be setting this variable, or is there a way to get EDE
>> to
>>> return the proper root directory?  Very likely, I've not set up my
>> EDE
>>> project correctly.
>>>
>>> Best,
>>> David
>>>
>>>> -----Original Message-----
>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>> Sent: Tuesday, May 04, 2010 4:41 PM
>>>> To: cedet-semantic@...
>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&   JDEE
>>> user
>>>> for a (mostly) Java project
>>>>
>>>> Looking in semantic-symref, I see that the location of GPATH (a GNU
>>>> Global tags file) needs to exist in the directory that is
> equivalent
>>> to
>>>> what EDE returns as the root directory.
>>>>
>>>> I think you can also set semantic-symref-tool to be 'global to turn
>>> off
>>>> the auto-detect feature.  In that case, I don't think anything
> needs
>>> to
>>>> match.
>>>>
>>>> Eric
>>>>
>>>> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
>>>>> Hi Eric,
>>>>>
>>>>> Sorry for not including that, but yes, I did.  The command
>>>>> cedet-gnu-global-show-root does indeed report the root directory
>>> that
>>>>> contains GTAGS, GRTAGS, etc.  If I cobble together a command to
>> call
>>>>> cedet-gnu-global-search, and then invoke that command while in a
>>> Java
>>>>> file below my project root, it seems to work.  I.e., I define:
>>>>>
>>>>> (defun foo ()
>>>>>      (interactive)
>>>>>      (cedet-gnu-global-search "getOpenReserves" 'string nil
>> 'project))
>>>>>
>>>>> Where "getOpenReserves" is the tag I'm cross-referencing.  If I
> run
>>>> the
>>>>> command foo while in a .java file, I get a *CEDET Global* buffer
>>> with
>>>>> the appropriate tags pulled from GTAGS.  Evidently,
> semantic-symref
>>>> and
>>>>> semantic-symref-global are not calling the cedet-gnu-global-search
>>>>> function in the right way.
>>>>>
>>>>> Best,
>>>>> David
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>> Sent: Tuesday, May 04, 2010 3:03 PM
>>>>>> To: David Ventimiglia
>>>>>> Cc: cedet-semantic@...
>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>> JDEE
>>>>> user
>>>>>> for a (mostly) Java project
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Did you you use the GNU global command  "gtags" to create the
>>> GLOBAL
>>>>>> database for your code?  I don't remember if you mentioned doing
>>>> that
>>>>>> or
>>>>>> not.  You need to create the GTAGS files before global will work
>> on
>>>>>> your
>>>>>> code.
>>>>>>
>>>>>> cedet-gnu-global-show-root
>>>>>>
>>>>>> will tell you if it is detecting GLOBAL files associated with
> your
>>>>>> directory or not.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
>>>>>>> Thanks, Eric.  Unfortunately, it resolutely insists on using
>> grep,
>>>>> or
>>>>>>> nothing at all, and I'm afraid there still must be something
>>>>>> fundamental
>>>>>>> I'm misunderstanding.  I made customizations in stepwise
> fashion:
>>>>>>>
>>>>>>> Step 1:  Added to .emacs
>>>>>>> (require 'cedet)
>>>>>>> (semantic-load-enable-code-helpers)
>>>>>>> (global-ede-mode 1)
>>>>>>> Result:  semantic-symref works, but uses grep
>>>>>>>
>>>>>>> Step 2:  Added to .emacs
>>>>>>> (require 'ede-locate)
>>>>>>> (setq ede-locate-setup-options
>>>>>>>           '(ede-locate-global
>>>>>>>             ede-locate-base))
>>>>>>> Result:  semantic-symref works, but uses grep
>>>>>>>
>>>>>>> Step 3:  Added to .emacs
>>>>>>> (require 'semantic-symref-grep)
>>>>>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
>>>>> "*.java"))
>>>>>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
>>>>>> "*.java"))
>>>>>>> Result:  semantic-symref works, but uses grep
>>>>>>>
>>>>>>> Step 4:  Used ede-new to create a Simple project, which landed
> in
>>>>>>> %HOME%/.ede/
>>>>>>> Result:  semantic-symref fails, reporting "No references found".
>>>>>>>
>>>>>>> Here's what the file in %HOME%/.ede/ looks like, where the
>>> contents
>>>>>> of
>>>>>>> :directory and :file just refer to things in my particular
>> project
>>>>>>> directory tree:
>>>>>>> ;; Object cc
>>>>>>> ;; EDE Simple Project
>>>>>>> (ede-simple-project "cc"
>>>>>>>       :name "cc"
>>>>>>>       :directory
>>>>>>> "c:/dev/eng/cc/denali/active/core/app-
>>>>>> cc/cc/src/com/guidewire/cc/domain/
>>>>>>> financials/impl/"
>>>>>>>       :file
>>>>>>> "!drive_c!dev!eng!cc!denali!active!core!app-
>>>>>> cc!cc!src!com!guidewire!cc!d
>>>>>>> omain!financials!impl!ProjSimple.ede"
>>>>>>>       :targets 'nil
>>>>>>>       )
>>>>>>>
>>>>>>> I must be missing something, but I'm afraid I just can't see
> what
>>>> it
>>>>>> is.
>>>>>>>
>>>>>>> Best,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>>>> Sent: Tuesday, May 04, 2010 1:26 PM
>>>>>>>> To: cedet-semantic@...
>>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>>>> JDEE
>>>>>>> user
>>>>>>>> for a (mostly) Java project
>>>>>>>>
>>>>>>>> If you use semantic-symref-data-debug-last-result it will show
>>> the
>>>>>>>> object that contains the data, and it is named after the tool
> it
>>>>>> uses,
>>>>>>>> like grep or global.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
>>>>>>>>> Thanks, Eric.  I think it might be working for me.  At least,
>>>> when
>>>>>> I
>>>>>>>> do
>>>>>>>>> semantic-symref on a Java function in my project, I get a
>> buffer
>>>>>>> with
>>>>>>>> a
>>>>>>>>> list of references.  It's a little slow, however, and I'm
>>>>> wondering
>>>>>>>> if
>>>>>>>>> it's falling back on Grep and not using my Global tags files.
>>>> The
>>>>>>>>> command cedet-gnu-global-show-root does show the right project
>>>>>> root,
>>>>>>>>> however.
>>>>>>>>>
>>>>>>>>> Question:  is there a way to verify it's using Global and not
>>>>> Grep?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Best,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
>>>>>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
>>>>>>>>>> To: David Ventimiglia
>>>>>>>>>> Cc: cedet-semantic@...
>>>>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
>>>>>> JDEE
>>>>>>>>> user
>>>>>>>>>> for a (mostly) Java project
>>>>>>>>>>
>>>>>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
>>>>>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced
> in
>>>>>>>> below.
>>>>>>>>>>>
>>>>>>>>>>>> The basic strategy is to get an EDE project pointing to the
>>>>> root
>>>>>>>> of
>>>>>>>>>>> all
>>>>>>>>>>>> your code.  I'm assuming all the languages you mentioned
> are
>>>> in
>>>>>>>> one
>>>>>>>>>>> big
>>>>>>>>>>>> mega-project.  That top level project then needs to know
>>> about
>>>>>>> all
>>>>>>>>>> the
>>>>>>>>>>>> targets.  For simplicity sake, you could have one target
> per
>>>>>>>>>> language
>>>>>>>>>>>> type, or more detailed, one target per language/directory.
>>>>>>>>>>>
>>>>>>>>>>> So far, I just started with ede-simple-project, which I
>>> created
>>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>>> command ede-new while visiting a Java file buried deep in
>> that
>>>>>>> part
>>>>>>>>>> of
>>>>>>>>>>> our source-tree.  This put a file in my $HOME/.ede directory
>>>>>>>>> defining
>>>>>>>>>>> that ede-simple-project.  I also have run GNU Global in my
>>>>>> project
>>>>>>>>>> root.
>>>>>>>>>>> What do I do now to enable completion, lookup, and
>>>>>>> cross-references
>>>>>>>>>> for
>>>>>>>>>>> symbols?
>>>>>>>>>>
>>>>>>>>>> Ah, good idea with the simple project.  I'd forgotten about
>>>> that.
>>>>>>>>>>
>>>>>>>>>> If you look in cedet/common/cedet.info in the node:
>>>>>>>>>>
>>>>>>>>>> (cedet.info)Top::>      GNU Global
>>>>>>>>>>
>>>>>>>>>> It lists all the options for enabling GNU Global in a CEDET
>>>>>>> project.
>>>>>>>>>>
>>>>>>>>>>>> As for the symbol references, you can use any of the
>>> different
>>>>>>>>> tools
>>>>>>>>>>>> you
>>>>>>>>>>>> prefer, or none.  If you try it (once you have an EDE
>> project
>>>>>>>>>>>> specifying
>>>>>>>>>>>> the root) with the find/grep solution and it is fast
> enough,
>>>>>> then
>>>>>>>>>> you
>>>>>>>>>>>> can consider yourself done.
>>>>>>>>>>>
>>>>>>>>>>> I made these customizations:
>>>>>>>>>>>
>>>>>>>>>>> (require 'cedet)
>>>>>>>>>>> (global-ede-mode 1)
>>>>>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
>>>>>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
>>>>>>>>>>> (setq ede-locate-setup-options
>>>>>>>>>>>             '(ede-locate-global
>>>>>>>>>>>               ede-locate-base))
>>>>>>>>>>>
>>>>>>>>>>> But when I invoke the command semantic-symref-symbol on some
>>>>>>> symbol
>>>>>>>>>> in a
>>>>>>>>>>> Java file, I get the message:
>>>>>>>>>>>
>>>>>>>>>>> semantic-symref-tool-grep - Needs to be configured for
>>> jde-mode
>>>>>>>>>>>
>>>>>>>>>>> What does this mean?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That means that semantic-symref-filepattern-alist needs to be
>>>>>>>>>> customized.  If you have a good customization, I'll add it to
>>>> the
>>>>>>>>>> default value.
>>>>>>>>>>
>>>>>>>>>> Probably something like:
>>>>>>>>>>
>>>>>>>>>> (add-to-list 'semantic-symref-filepattern-alist
>>>>>>>>>> 	'(jde-mode "*.java"))
>>>>>>>>>>
>>>>>>>>>> I'll fix the error message to be more obvious.
>>>>>>>>>>
>>>>>>>>>> Of course, this also means that it failed to auto-detect the
>>> GNU
>>>>>>>>> Global
>>>>>>>>>> tags file at the root of your project.  Use  M-x
>>>>>>>>>> cedet-gnu-global-show-root to determine if the detection is
>>>>>>> working.
>>>>>>>>>> If
>>>>>>>>>> it fails, then there is something in the Global doc that
> might
>>>>>>> help,
>>>>>>>>>> since CEDET just calls global with "-pq" options.
>>>>>>>>>>
>>>>>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
>>>>> symbol
>>>>>>>>>>> lookups?  Is it possible just to rely on the CEDET tools
>>> alone?
>>>>>>>>>>
>>>>>>>>>> The symref tool relies on at least one external tool, but it
>>> can
>>>>>>> use
>>>>>>>>>> find/grep commands to do it, so the other tools are not
>>>> required,
>>>>>>>> but
>>>>>>>>>> will instead provide better and faster results.
>>>>>>>>>>
>>>>>>>>>>       >What I
>>>>>>>>>>> mean is, I gather that semantic is parsing and caching the
>>> tags
>>>>>>>> for,
>>>>>>>>>>> say, the Java files that I visit.  Is it possible to have
>>>>>> semantic
>>>>>>>>>> parse
>>>>>>>>>>
>>>>>>>>>> Semantic only parses the tags (like ctags) and not the
>>> contents.
>>>>>>>>>>
>>>>>>>>>>> ALL my Java source files ahead of time (a la Global,
> idutils,
>>>>>>>> ctags,
>>>>>>>>>>> etc.), then just use semanticdb to support completion,
>> lookup,
>>>>>> and
>>>>>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying
> to
>>>>>>>>>> evangelize
>>>>>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop, and
>>>> the
>>>>>>>>> more
>>>>>>>>>>> external tools I have to integrate (like finding Windows
>>>>> versions
>>>>>>>> of
>>>>>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
>>>> would
>>>>>>> it
>>>>>>>>>>> simply be too much of a performance hit to ask semantic to
> do
>>>>>> what
>>>>>>>>>>> Global et al are optimized to do very fast?
>>>>>>>>>>
>>>>>>>>>> Semantic parses it's own tags because tools like global and
>>>> ctags
>>>>>>>>>> provide only "quickie" information, and take many short-cuts
>> to
>>>>> do
>>>>>>>> so.
>>>>>>>>>> To do what CEDET does with tags, it needs to be much more
>>>>> careful.
>>>>>>>>>>
>>>>>>>>>> Semantic also already has trouble with really huge projects,
>>> and
>>>>>>>> Emacs
>>>>>>>>>> Lisp is just the wrong language to implement symbol cross-
>>>>>> reference
>>>>>>>>>> database in do the shear size.
>>>>>>>>>>
>>>>>>>>>> Instead, things like Global do a pretty good job on
>> references,
>>>>> so
>>>>>>> I
>>>>>>>>>> use
>>>>>>>>>> those instead, and deal with the inaccuracy of it.  I'm
> hoping
>>>> to
>>>>>>>>>> double-check each "hit" with a real analysis to prove that
> the
>>>>> hit
>>>>>>>> is
>>>>>>>>>> really a reference to a given symbol, and not some
> side-effect
>>>> of
>>>>>>>>>> polymorphism or other trick.
>>>>>>>>>>
>>>>>>>>>> Anyway, Global is probably your best bet unless find/grep is
>>>> fast
>>>>>>>>>> enough
>>>>>>>>>> for you.
>>>>>>>>>>
>>>>>>>>>> Good Luck!
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>> _______________________________________________
>>>>>>>>> cedet-semantic mailing list
>>>>>>>>> cedet-semantic@...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>>>> --
>>>>>>>> -------
>>>>>>>> _______________________________________________
>>>>>>>> cedet-semantic mailing list
>>>>>>>> cedet-semantic@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>>>
>>>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>>>> ---------
>>>>>>> _______________________________________________
>>>>>>> cedet-semantic mailing list
>>>>>>> cedet-semantic@...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>>>
>>>>>
>>>>>
>>>
> ---------------------------------------------------------------------
>>>> ---------
>>>>> _______________________________________________
>>>>> cedet-semantic mailing list
>>>>> cedet-semantic@...
>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>>>
>>>>
>>>>
>>>
> ---------------------------------------------------------------------
>> --
>>>> -------
>>>> _______________________________________________
>>>> cedet-semantic mailing list
>>>> cedet-semantic@...
>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Thanks, Eric.  I started doing some debugging last night and will
continue later today.  I'm afraid I'm not using any Unixy automounters,
as this is occurring on Windows.  I'll check and see if it happens on
Linux tonight.

So, is the :directory parameter of ede-simple-project the thing that
defines the project root?  I figure that must be the case.  Also, is
there a way to have the project files reside not in %HOME%/.ede, but
rather in the actual source tree itself, say at the root?  The reason
being that it could then be checked into source control for that
project, so that other users wouldn't have to mess with it.  

As always, thanks for your help.

All the best,
David

> -----Original Message-----
> From: Eric M. Ludlam [mailto:eric@...]
> Sent: Wednesday, May 05, 2010 4:01 AM
> To: cedet-semantic@...
> Subject: Re: [cedet-semantic] Recommendations for new CEDET & JDEE
user
> for a (mostly) Java project
> 
> Well, it looks like the simple project type isn't working.  I ran a
> quick interactive test for simple projects and it seems to work for me
> in terms of getting (ede-toplevel) to return the correct project type.
> 
> Do you use automounters or other unixy things where /home/project
might
> also be seen as /automout/home/project or something like that?
> 
> I think the next thing to do is visit ede-simple.el, and use edebug on
> ede-simple-projectfile-for-dir (by putting the cursor in there and
> typing M-x edebug-defun) and then visit a file in your project.  The
> translation from dir to project can then be stepped through using SPC
> to
> see what is going on.
> 
> Eric
> 
> On 05/05/2010 12:31 AM, David Ventimiglia wrote:
> > Yes, but how do I make sure that the root of my EDE project is the
> same
> > location of my GPATH file?  I invoked ede-new from a Java file deep
> in
> > my source tree, so that the file in %HOME%/.ede has a long name with
> the
> > fully-qualified path to that Java file embedded in the name (with
> bangs
> > in place of the path separator), and inside that file it invokes
> > ede-simple-project with the keyword argument :directory set to the
> > directory containing that file, which again is deep into my source
> tree.
> > Does that mean my EDE root is set to that subdirectory?  That would
> be a
> > problem, because that's not where my GPATH file is.  GPATH is in the
> > true root of my project, which is like 5 directories up.  Should I
> > hand-edit the project file?  I tried that, setting :directory to the
> > actual root of my project (the directory containing GPATH), but
still
> no
> > dice.
> >
> > Either way, it appears not to be finding and/or reading the project
> file
> > correctly, since running (semantic-symref-detect-symref-tool)
returns
> > grep.  (ede-toplevel) returns nil, I guess because
> > ede-directory-get-open-project and ede-directory-project-p return
nil
> > for default-directory.
> >
> >> -----Original Message-----
> >> From: Eric M. Ludlam [mailto:eric@...]
> >> Sent: Tuesday, May 04, 2010 5:51 PM
> >> To: David Ventimiglia
> >> Cc: cedet-semantic@...
> >> Subject: Re: [cedet-semantic] Recommendations for new CEDET&  JDEE
> > user
> >> for a (mostly) Java project
> >>
> >> I think all you need to do is make sure that the root of your EDE
> >> project is the same location as the location of your GPATH file, or
> >> where you ran gtags from.
> >>
> >> If you work on lots of different projects with different tagging
> >> schemes, then you want the autodetect feature.  If you always work
> on
> >> the same thing, then it doesn't really matter.
> >>
> >> Eric
> >>
> >> On 05/04/2010 07:52 PM, David Ventimiglia wrote:
> >>> Great!  That worked!  I added this to java-mode-hook:
> >>>
> >>> (lambda () (setq semantic-symref-tool 'global))
> >>>
> >>> So, should I be setting this variable, or is there a way to get
EDE
> >> to
> >>> return the proper root directory?  Very likely, I've not set up my
> >> EDE
> >>> project correctly.
> >>>
> >>> Best,
> >>> David
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>> Sent: Tuesday, May 04, 2010 4:41 PM
> >>>> To: cedet-semantic@...
> >>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> JDEE
> >>> user
> >>>> for a (mostly) Java project
> >>>>
> >>>> Looking in semantic-symref, I see that the location of GPATH (a
> GNU
> >>>> Global tags file) needs to exist in the directory that is
> > equivalent
> >>> to
> >>>> what EDE returns as the root directory.
> >>>>
> >>>> I think you can also set semantic-symref-tool to be 'global to
> turn
> >>> off
> >>>> the auto-detect feature.  In that case, I don't think anything
> > needs
> >>> to
> >>>> match.
> >>>>
> >>>> Eric
> >>>>
> >>>> On 05/04/2010 07:19 PM, David Ventimiglia wrote:
> >>>>> Hi Eric,
> >>>>>
> >>>>> Sorry for not including that, but yes, I did.  The command
> >>>>> cedet-gnu-global-show-root does indeed report the root directory
> >>> that
> >>>>> contains GTAGS, GRTAGS, etc.  If I cobble together a command to
> >> call
> >>>>> cedet-gnu-global-search, and then invoke that command while in a
> >>> Java
> >>>>> file below my project root, it seems to work.  I.e., I define:
> >>>>>
> >>>>> (defun foo ()
> >>>>>      (interactive)
> >>>>>      (cedet-gnu-global-search "getOpenReserves" 'string nil
> >> 'project))
> >>>>>
> >>>>> Where "getOpenReserves" is the tag I'm cross-referencing.  If I
> > run
> >>>> the
> >>>>> command foo while in a .java file, I get a *CEDET Global* buffer
> >>> with
> >>>>> the appropriate tags pulled from GTAGS.  Evidently,
> > semantic-symref
> >>>> and
> >>>>> semantic-symref-global are not calling the cedet-gnu-global-
> search
> >>>>> function in the right way.
> >>>>>
> >>>>> Best,
> >>>>> David
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>> Sent: Tuesday, May 04, 2010 3:03 PM
> >>>>>> To: David Ventimiglia
> >>>>>> Cc: cedet-semantic@...
> >>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >> JDEE
> >>>>> user
> >>>>>> for a (mostly) Java project
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Did you you use the GNU global command  "gtags" to create the
> >>> GLOBAL
> >>>>>> database for your code?  I don't remember if you mentioned
doing
> >>>> that
> >>>>>> or
> >>>>>> not.  You need to create the GTAGS files before global will
work
> >> on
> >>>>>> your
> >>>>>> code.
> >>>>>>
> >>>>>> cedet-gnu-global-show-root
> >>>>>>
> >>>>>> will tell you if it is detecting GLOBAL files associated with
> > your
> >>>>>> directory or not.
> >>>>>>
> >>>>>> Eric
> >>>>>>
> >>>>>> On 05/04/2010 05:40 PM, David Ventimiglia wrote:
> >>>>>>> Thanks, Eric.  Unfortunately, it resolutely insists on using
> >> grep,
> >>>>> or
> >>>>>>> nothing at all, and I'm afraid there still must be something
> >>>>>> fundamental
> >>>>>>> I'm misunderstanding.  I made customizations in stepwise
> > fashion:
> >>>>>>>
> >>>>>>> Step 1:  Added to .emacs
> >>>>>>> (require 'cedet)
> >>>>>>> (semantic-load-enable-code-helpers)
> >>>>>>> (global-ede-mode 1)
> >>>>>>> Result:  semantic-symref works, but uses grep
> >>>>>>>
> >>>>>>> Step 2:  Added to .emacs
> >>>>>>> (require 'ede-locate)
> >>>>>>> (setq ede-locate-setup-options
> >>>>>>>           '(ede-locate-global
> >>>>>>>             ede-locate-base))
> >>>>>>> Result:  semantic-symref works, but uses grep
> >>>>>>>
> >>>>>>> Step 3:  Added to .emacs
> >>>>>>> (require 'semantic-symref-grep)
> >>>>>>> (add-to-list 'semantic-symref-filepattern-alist '(jde-mode
> >>>>> "*.java"))
> >>>>>>> (add-to-list 'semantic-symref-filepattern-alist '(java-mode
> >>>>>> "*.java"))
> >>>>>>> Result:  semantic-symref works, but uses grep
> >>>>>>>
> >>>>>>> Step 4:  Used ede-new to create a Simple project, which landed
> > in
> >>>>>>> %HOME%/.ede/
> >>>>>>> Result:  semantic-symref fails, reporting "No references
> found".
> >>>>>>>
> >>>>>>> Here's what the file in %HOME%/.ede/ looks like, where the
> >>> contents
> >>>>>> of
> >>>>>>> :directory and :file just refer to things in my particular
> >> project
> >>>>>>> directory tree:
> >>>>>>> ;; Object cc
> >>>>>>> ;; EDE Simple Project
> >>>>>>> (ede-simple-project "cc"
> >>>>>>>       :name "cc"
> >>>>>>>       :directory
> >>>>>>> "c:/dev/eng/cc/denali/active/core/app-
> >>>>>> cc/cc/src/com/guidewire/cc/domain/
> >>>>>>> financials/impl/"
> >>>>>>>       :file
> >>>>>>> "!drive_c!dev!eng!cc!denali!active!core!app-
> >>>>>> cc!cc!src!com!guidewire!cc!d
> >>>>>>> omain!financials!impl!ProjSimple.ede"
> >>>>>>>       :targets 'nil
> >>>>>>>       )
> >>>>>>>
> >>>>>>> I must be missing something, but I'm afraid I just can't see
> > what
> >>>> it
> >>>>>> is.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> David
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>>>> Sent: Tuesday, May 04, 2010 1:26 PM
> >>>>>>>> To: cedet-semantic@...
> >>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new CEDET&
> >>>> JDEE
> >>>>>>> user
> >>>>>>>> for a (mostly) Java project
> >>>>>>>>
> >>>>>>>> If you use semantic-symref-data-debug-last-result it will
show
> >>> the
> >>>>>>>> object that contains the data, and it is named after the tool
> > it
> >>>>>> uses,
> >>>>>>>> like grep or global.
> >>>>>>>>
> >>>>>>>> Eric
> >>>>>>>>
> >>>>>>>> On 05/04/2010 01:42 PM, David Ventimiglia wrote:
> >>>>>>>>> Thanks, Eric.  I think it might be working for me.  At
least,
> >>>> when
> >>>>>> I
> >>>>>>>> do
> >>>>>>>>> semantic-symref on a Java function in my project, I get a
> >> buffer
> >>>>>>> with
> >>>>>>>> a
> >>>>>>>>> list of references.  It's a little slow, however, and I'm
> >>>>> wondering
> >>>>>>>> if
> >>>>>>>>> it's falling back on Grep and not using my Global tags
files.
> >>>> The
> >>>>>>>>> command cedet-gnu-global-show-root does show the right
> project
> >>>>>> root,
> >>>>>>>>> however.
> >>>>>>>>>
> >>>>>>>>> Question:  is there a way to verify it's using Global and
not
> >>>>> Grep?
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>> Best,
> >>>>>>>>> David
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Eric M. Ludlam [mailto:eric@...]
> >>>>>>>>>> Sent: Sunday, May 02, 2010 5:47 AM
> >>>>>>>>>> To: David Ventimiglia
> >>>>>>>>>> Cc: cedet-semantic@...
> >>>>>>>>>> Subject: Re: [cedet-semantic] Recommendations for new
CEDET&
> >>>>>> JDEE
> >>>>>>>>> user
> >>>>>>>>>> for a (mostly) Java project
> >>>>>>>>>>
> >>>>>>>>>> On 04/30/2010 08:31 PM, David Ventimiglia wrote:
> >>>>>>>>>>> Thanks, Eric.  I've a few, more-specific questions spliced
> > in
> >>>>>>>> below.
> >>>>>>>>>>>
> >>>>>>>>>>>> The basic strategy is to get an EDE project pointing to
> the
> >>>>> root
> >>>>>>>> of
> >>>>>>>>>>> all
> >>>>>>>>>>>> your code.  I'm assuming all the languages you mentioned
> > are
> >>>> in
> >>>>>>>> one
> >>>>>>>>>>> big
> >>>>>>>>>>>> mega-project.  That top level project then needs to know
> >>> about
> >>>>>>> all
> >>>>>>>>>> the
> >>>>>>>>>>>> targets.  For simplicity sake, you could have one target
> > per
> >>>>>>>>>> language
> >>>>>>>>>>>> type, or more detailed, one target per
language/directory.
> >>>>>>>>>>>
> >>>>>>>>>>> So far, I just started with ede-simple-project, which I
> >>> created
> >>>>>>>> with
> >>>>>>>>>> the
> >>>>>>>>>>> command ede-new while visiting a Java file buried deep in
> >> that
> >>>>>>> part
> >>>>>>>>>> of
> >>>>>>>>>>> our source-tree.  This put a file in my $HOME/.ede
> directory
> >>>>>>>>> defining
> >>>>>>>>>>> that ede-simple-project.  I also have run GNU Global in my
> >>>>>> project
> >>>>>>>>>> root.
> >>>>>>>>>>> What do I do now to enable completion, lookup, and
> >>>>>>> cross-references
> >>>>>>>>>> for
> >>>>>>>>>>> symbols?
> >>>>>>>>>>
> >>>>>>>>>> Ah, good idea with the simple project.  I'd forgotten about
> >>>> that.
> >>>>>>>>>>
> >>>>>>>>>> If you look in cedet/common/cedet.info in the node:
> >>>>>>>>>>
> >>>>>>>>>> (cedet.info)Top::>      GNU Global
> >>>>>>>>>>
> >>>>>>>>>> It lists all the options for enabling GNU Global in a CEDET
> >>>>>>> project.
> >>>>>>>>>>
> >>>>>>>>>>>> As for the symbol references, you can use any of the
> >>> different
> >>>>>>>>> tools
> >>>>>>>>>>>> you
> >>>>>>>>>>>> prefer, or none.  If you try it (once you have an EDE
> >> project
> >>>>>>>>>>>> specifying
> >>>>>>>>>>>> the root) with the find/grep solution and it is fast
> > enough,
> >>>>>> then
> >>>>>>>>>> you
> >>>>>>>>>>>> can consider yourself done.
> >>>>>>>>>>>
> >>>>>>>>>>> I made these customizations:
> >>>>>>>>>>>
> >>>>>>>>>>> (require 'cedet)
> >>>>>>>>>>> (global-ede-mode 1)
> >>>>>>>>>>> (semanticdb-enable-gnu-global-databases 'java-mode)
> >>>>>>>>>>> (semanticdb-enable-gnu-global-databases 'jde-mode)
> >>>>>>>>>>> (setq ede-locate-setup-options
> >>>>>>>>>>>             '(ede-locate-global
> >>>>>>>>>>>               ede-locate-base))
> >>>>>>>>>>>
> >>>>>>>>>>> But when I invoke the command semantic-symref-symbol on
> some
> >>>>>>> symbol
> >>>>>>>>>> in a
> >>>>>>>>>>> Java file, I get the message:
> >>>>>>>>>>>
> >>>>>>>>>>> semantic-symref-tool-grep - Needs to be configured for
> >>> jde-mode
> >>>>>>>>>>>
> >>>>>>>>>>> What does this mean?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> That means that semantic-symref-filepattern-alist needs to
> be
> >>>>>>>>>> customized.  If you have a good customization, I'll add it
> to
> >>>> the
> >>>>>>>>>> default value.
> >>>>>>>>>>
> >>>>>>>>>> Probably something like:
> >>>>>>>>>>
> >>>>>>>>>> (add-to-list 'semantic-symref-filepattern-alist
> >>>>>>>>>> 	'(jde-mode "*.java"))
> >>>>>>>>>>
> >>>>>>>>>> I'll fix the error message to be more obvious.
> >>>>>>>>>>
> >>>>>>>>>> Of course, this also means that it failed to auto-detect
the
> >>> GNU
> >>>>>>>>> Global
> >>>>>>>>>> tags file at the root of your project.  Use  M-x
> >>>>>>>>>> cedet-gnu-global-show-root to determine if the detection is
> >>>>>>> working.
> >>>>>>>>>> If
> >>>>>>>>>> it fails, then there is something in the Global doc that
> > might
> >>>>>>> help,
> >>>>>>>>>> since CEDET just calls global with "-pq" options.
> >>>>>>>>>>
> >>>>>>>>>>> Finally, must one use Global, idutils, locate, etc., to do
> >>>>> symbol
> >>>>>>>>>>> lookups?  Is it possible just to rely on the CEDET tools
> >>> alone?
> >>>>>>>>>>
> >>>>>>>>>> The symref tool relies on at least one external tool, but
it
> >>> can
> >>>>>>> use
> >>>>>>>>>> find/grep commands to do it, so the other tools are not
> >>>> required,
> >>>>>>>> but
> >>>>>>>>>> will instead provide better and faster results.
> >>>>>>>>>>
> >>>>>>>>>>       >What I
> >>>>>>>>>>> mean is, I gather that semantic is parsing and caching the
> >>> tags
> >>>>>>>> for,
> >>>>>>>>>>> say, the Java files that I visit.  Is it possible to have
> >>>>>> semantic
> >>>>>>>>>> parse
> >>>>>>>>>>
> >>>>>>>>>> Semantic only parses the tags (like ctags) and not the
> >>> contents.
> >>>>>>>>>>
> >>>>>>>>>>> ALL my Java source files ahead of time (a la Global,
> > idutils,
> >>>>>>>> ctags,
> >>>>>>>>>>> etc.), then just use semanticdb to support completion,
> >> lookup,
> >>>>>> and
> >>>>>>>>>>> cross-referencing?  This isn't a huge deal, but I'm trying
> > to
> >>>>>>>>>> evangelize
> >>>>>>>>>>> Emacs+CEDET+JDEE at my company, which is a Windows shop,
> and
> >>>> the
> >>>>>>>>> more
> >>>>>>>>>>> external tools I have to integrate (like finding Windows
> >>>>> versions
> >>>>>>>> of
> >>>>>>>>>>> Global, idutils, etc.), the harder that sell becomes.  Or,
> >>>> would
> >>>>>>> it
> >>>>>>>>>>> simply be too much of a performance hit to ask semantic to
> > do
> >>>>>> what
> >>>>>>>>>>> Global et al are optimized to do very fast?
> >>>>>>>>>>
> >>>>>>>>>> Semantic parses it's own tags because tools like global and
> >>>> ctags
> >>>>>>>>>> provide only "quickie" information, and take many
short-cuts
> >> to
> >>>>> do
> >>>>>>>> so.
> >>>>>>>>>> To do what CEDET does with tags, it needs to be much more
> >>>>> careful.
> >>>>>>>>>>
> >>>>>>>>>> Semantic also already has trouble with really huge
projects,
> >>> and
> >>>>>>>> Emacs
> >>>>>>>>>> Lisp is just the wrong language to implement symbol cross-
> >>>>>> reference
> >>>>>>>>>> database in do the shear size.
> >>>>>>>>>>
> >>>>>>>>>> Instead, things like Global do a pretty good job on
> >> references,
> >>>>> so
> >>>>>>> I
> >>>>>>>>>> use
> >>>>>>>>>> those instead, and deal with the inaccuracy of it.  I'm
> > hoping
> >>>> to
> >>>>>>>>>> double-check each "hit" with a real analysis to prove that
> > the
> >>>>> hit
> >>>>>>>> is
> >>>>>>>>>> really a reference to a given symbol, and not some
> > side-effect
> >>>> of
> >>>>>>>>>> polymorphism or other trick.
> >>>>>>>>>>
> >>>>>>>>>> Anyway, Global is probably your best bet unless find/grep
is
> >>>> fast
> >>>>>>>>>> enough
> >>>>>>>>>> for you.
> >>>>>>>>>>
> >>>>>>>>>> Good Luck!
> >>>>>>>>>> Eric
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>>>>>> ---------
> >>>>>>>>> _______________________________________________
> >>>>>>>>> cedet-semantic mailing list
> >>>>>>>>> cedet-semantic@...
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>>>> --
> >>>>>>>> -------
> >>>>>>>> _______________________________________________
> >>>>>>>> cedet-semantic mailing list
> >>>>>>>> cedet-semantic@...
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>>>> ---------
> >>>>>>> _______________________________________________
> >>>>>>> cedet-semantic mailing list
> >>>>>>> cedet-semantic@...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
---------------------------------------------------------------------
> >>>> ---------
> >>>>> _______________________________________________
> >>>>> cedet-semantic mailing list
> >>>>> cedet-semantic@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>>>
> >>>>
> >>>>
> >>>
> >
---------------------------------------------------------------------
> >> --
> >>>> -------
> >>>> _______________________________________________
> >>>> cedet-semantic mailing list
> >>>> cedet-semantic@...
> >>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >>>
> >
> >
---------------------------------------------------------------------
> ---------
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> 
>
-----------------------------------------------------------------------
> -------
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic