CEDET

>>> "Andrey Zhdanov" <susuman@...> seems to think that:
>Could someone finally fix regexp in ede-up-directory to match lower case 
>drive letters?
>Should be: (if (string-match "^[a-zA-Z]:[\\/]$" dir)
>(Speedbar sets case-sensitive match and loops infinitely)
>http://sourceforge.net/mailarchive/message.php?msg_id=14752327 
  [ ... ]

I've checked this into CEDET CVS.  Thanks for the reminder.  I haven't
really been available for this sort thing in the past couple years.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

If you built CEDET with the makefiles, and had a few .elc files
floating about as left overs from a previous install, then EIEIO can
sometimes terminate a byte-compile without throwing an error.  I don't
know how that happens since you can't catch what it doesn't throw, but
anyway, to fix, delete the .elc, and byte compile again.  Using the
clean-all target will usually do it.

Eric

>>> "Philipp Robbel" <robbel@...> seems to think that:
>Hi,
>
>I performed a new CVS checkout about 3 days ago and now, whenever I
>attempt to open a C file, get the following notice in the Emacs
>*Messages* buffer (this was not the case for the previous months that
>I have been using cedet):
>
>File mode specification error: (error "Autoloading failed to define
>function semantic-default-c-setup")
>
>The .emacs lines relevant to my cedet setup file are as follows:
>
>---------------------------------------
>; Load CEDET extensions
>(load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
>(semantic-load-enable-guady-code-helpers)
>(global-semantic-stickyfunc-mode nil)
>(global-semantic-decoration-mode nil)
>(which-func-mode t)
>
>; Set semantic cache directory
>(setq semanticdb-default-save-directory "~/.semantic.cache")
>---------------------------------------
>
>I admit I performed an Emacs CVS checkout at the same time so I'm not
>sure whether to attribute this to changed Emacs or cedet behavior..
>
>I appreciate your help,
>Philipp
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Cedet-devel mailing list
>Cedet-devel@...
>https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

Hi Eric,

I just tried the make clean-all + recompile way but I still get
exactly the same error when I open any *.c file.. do you happen to
have any other idea why i might get such an error?

Thanks again,
Philipp

On 2/26/07, Eric M. Ludlam <eric@...> wrote:
> If you built CEDET with the makefiles, and had a few .elc files
> floating about as left overs from a previous install, then EIEIO can
> sometimes terminate a byte-compile without throwing an error.  I don't
> know how that happens since you can't catch what it doesn't throw, but
> anyway, to fix, delete the .elc, and byte compile again.  Using the
> clean-all target will usually do it.
>
> Eric
>
> >>> "Philipp Robbel" <robbel@...> seems to think that:
> >Hi,
> >
> >I performed a new CVS checkout about 3 days ago and now, whenever I
> >attempt to open a C file, get the following notice in the Emacs
> >*Messages* buffer (this was not the case for the previous months that
> >I have been using cedet):
> >
> >File mode specification error: (error "Autoloading failed to define
> >function semantic-default-c-setup")
> >
> >The .emacs lines relevant to my cedet setup file are as follows:
> >
> >---------------------------------------
> >; Load CEDET extensions
> >(load-file "/usr/share/emacs/site-lisp/cedet/common/cedet.el")
> >(semantic-load-enable-guady-code-helpers)
> >(global-semantic-stickyfunc-mode nil)
> >(global-semantic-decoration-mode nil)
> >(which-func-mode t)
> >
> >; Set semantic cache directory
> >(setq semanticdb-default-save-directory "~/.semantic.cache")
> >---------------------------------------
> >
> >I admit I performed an Emacs CVS checkout at the same time so I'm not
> >sure whether to attribute this to changed Emacs or cedet behavior..
> >
> >I appreciate your help,
> >Philipp
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share your
> >opinions on IT & business topics through brief surveys-and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >Cedet-devel mailing list
> >Cedet-devel@...
> >https://lists.sourceforge.net/lists/listinfo/cedet-devel
> >
>

"Eric M. Ludlam" <eric@...> writes:

> Your below example was excellent.  It exposed an area of namespaces
> that wasn't yet supported.  I was able to fix the second problem in
> semantic-c.el, and semantic-analize.el such that it worked for your
> below example.

Sweet!

> If you could get the latest from CVS and let me know how it goes,
> I would be most appreciative.

An attempt to build...

# Because of "Makefile is out of date! It needs to be regenerated by EDE.
# If you have not modified Project.ede, you can use touch to update
# the Makefile time stamp." message
touch **/Makefile

make clean-autoloads
make clean-all
make EMACS=/usr/local/emacs-cvs/bin/emacs

...the CVS version results to:

"/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy
Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el
Package `semantic-grammar-wy' is up to date.

In toplevel form:
semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed
make[1]: *** [metagrammar] Error 1
make[1]: Leaving directory `/home/foo/cedet/semantic'
make: *** [semantic] Error 2

The sad part is that I actually faced the same problem the previous
time and somehow managed to get rid of it but I no longer remember how...

> A good way to check when you encounter an issue is with:
> M-x semantic-analyze-current-context RET
>
> If the Prefix slot doesn't have any type information, then the rest of
> the system will fail.

Thanks for the tip.

-- 
Hannu

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> Your below example was excellent.  It exposed an area of namespaces
>> that wasn't yet supported.  I was able to fix the second problem in
>> semantic-c.el, and semantic-analize.el such that it worked for your
>> below example.
>
>Sweet!
>
>> If you could get the latest from CVS and let me know how it goes,
>> I would be most appreciative.
>
>An attempt to build...
>
># Because of "Makefile is out of date! It needs to be regenerated by EDE.
># If you have not modified Project.ede, you can use touch to update
># the Makefile time stamp." message
>touch **/Makefile

Yea, one thing I've learned is that I should have named the project
file AProject.ede so that when a CVS checkout occurs, this doesn't
happen. ;)

>make clean-autoloads
>make clean-all
>make EMACS=/usr/local/emacs-cvs/bin/emacs
>
>...the CVS version results to:
>
>"/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy
>Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el
>Package `semantic-grammar-wy' is up to date.
>
>In toplevel form:
>semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed
>make[1]: *** [metagrammar] Error 1
>make[1]: Leaving directory `/home/foo/cedet/semantic'
>make: *** [semantic] Error 2

Hmmm.  I haven't updated that file since last fall.

>The sad part is that I actually faced the same problem the previous
>time and somehow managed to get rid of it but I no longer remember how...

I tried your steps in my checkout-only copy of cedet w/out being able
to repro it.

If, in Emacs, you use 

C-x v d ~/path/to/cedet RET

it will let you know if any files related to that grammar are modified
locally, or out of date.

While I haven't seen that specific error, when someone bumps into a
problem with that grammar file, I usually suggest that they delete it,
and then "cvs up semantic-grammar-wy.el" to fetch a new one from CVS,
and that has always worked.

Thanks
Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

>>"/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy
>>Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el
>>Package `semantic-grammar-wy' is up to date.
>>
>>In toplevel form:
>>semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed
>>make[1]: *** [metagrammar] Error 1
>>make[1]: Leaving directory `/home/foo/cedet/semantic'
>>make: *** [semantic] Error 2
>
> Hmmm.  I haven't updated that file since last fall.
>
>>The sad part is that I actually faced the same problem the previous
>>time and somehow managed to get rid of it but I no longer remember how...
>
> I tried your steps in my checkout-only copy of cedet w/out being able
> to repro it.
>
> If, in Emacs, you use 
>
> C-x v d ~/path/to/cedet RET
>
> it will let you know if any files related to that grammar are modified
> locally, or out of date.
>
> While I haven't seen that specific error, when someone bumps into a
> problem with that grammar file, I usually suggest that they delete it,
> and then "cvs up semantic-grammar-wy.el" to fetch a new one from CVS,
> and that has always worked.

I made a completely new checkout on a different machine (than my
previous CEDET test) so that cannot be the issue.  And I now
explicitly checked it's up-to-date.  I tested a bit more and
apparently Debian's Emacs 21.4 can compile semantic-grammar-wy.el
without that problem (I first tried with Emacs 22-CVS-20051218
which I have on this other machine as well) so it would seem to
suggest that this is an Emacs problem.  I only wonder how on earth
I managed to get CEDET to build on my home machine with that same
Emacs CVS version.  Or maybe I built it with 21.4 and then used
with the CVS version...  Now that I tried it seems to work so I'll
continue testing that way.

Sorry for the noise, I guess I finally have to upgrade if I want to
continue using the development version.

Completion still doesn't work in my real case.  I'll try to make an
updated small test case that can be used to reproduce the problem.

-- 
Hannu

"Eric M. Ludlam" <eric@...> writes:

> Your below example was excellent.  It exposed an area of namespaces
> that wasn't yet supported.  I was able to fix the second problem in
> semantic-c.el, and semantic-analize.el such that it worked for your
> below example.
>
> If you could get the latest from CVS and let me know how it goes,
> I would be most appreciative.

The CVS version indeed worked for my example but it seems my
example was too simple to correspond to the real case I was having
problems with.  Here's un updated version:

---foo.hpp--------------------------------------------------------
namespace a {
namespace b {

class Quux;

} // namespace b

b::Quux& getQuux();

} // namespace a
---foo.hpp--------------------------------------------------------

---quux.hpp-------------------------------------------------------
namespace a {
namespace b {

class Quux {
public:
    void dum() { }
    void dam() { }
};

}
}
---quux.hpp-------------------------------------------------------

---foo.cpp--------------------------------------------------------
#include "foo.hpp"
#include "quux.hpp"

namespace a {
namespace c {

void dum() {
    b::Quux& theQuux = getQuux();
    theQuux.<M-x semantic-ia-complete-symbol-menu> => bogus completions
}

}
}
---foo.cpp--------------------------------------------------------

That is, within dum() in foo.cpp it can't complete b::Quux members
but instead gives me:

* getQuux () : class b::Quux
* theQuux : class b::Quux

> A good way to check when you encounter an issue is with:
> M-x semantic-analyze-current-context RET

This gives me:

Context Type: #<semantic-analyze-context context>
Bounds: (129 . 129)
Prefix: class b::Quux theQuux
        ""
Prefix Classes: 'function
                'variable
Prefix Types: 'nil
--------
Scope Types: namespace a {}
             namespace c {}
Scope: foo.hpp
       quux.hpp
       namespace a {}
       namespace a {}
       namespace b {}
       class b::Quux getQuux ()
       namespace c {}
LocalVars: class b::Quux theQuux

-- 
Hannu

Hi,

  Thanks for the example.  When I created those files, I got the
dum/dam completions.  Suspicious, I swapped the order of the #include
statements, and then I replicated the problem you saw.

  One of the features I added to the analyzer recently for your
examples was the ability to merge multiple namespace instances
together.  My suspicion at the time was that this could end up being
very slow for very large namespaces, but in this case, it just isn't
working.

  I'm going to investigate this problem, but I may end up getting
side-tracked on some sort of namespace/type manager because dealing
with it in the analyzer for every query is wasteful.

  As usual, I'll be posting about it as I go.  Be a bit patient with
me, as I feel it is important to get good C++ completion working for
the CEDET 1.0 release, as without it, CEDET won't be very useful to
C++ users.

Thanks
Eric

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> Your below example was excellent.  It exposed an area of namespaces
>> that wasn't yet supported.  I was able to fix the second problem in
>> semantic-c.el, and semantic-analize.el such that it worked for your
>> below example.
>>
>> If you could get the latest from CVS and let me know how it goes,
>> I would be most appreciative.
>
>The CVS version indeed worked for my example but it seems my
>example was too simple to correspond to the real case I was having
>problems with.  Here's un updated version:
>
>---foo.hpp--------------------------------------------------------
>namespace a {
>namespace b {
>
>class Quux;
>
>} // namespace b
>
>b::Quux& getQuux();
>
>} // namespace a
>---foo.hpp--------------------------------------------------------
>
>---quux.hpp-------------------------------------------------------
>namespace a {
>namespace b {
>
>class Quux {
>public:
>    void dum() { }
>    void dam() { }
>};
>
>}
>}
>---quux.hpp-------------------------------------------------------
>
>---foo.cpp--------------------------------------------------------
>#include "foo.hpp"
>#include "quux.hpp"
>
>namespace a {
>namespace c {
>
>void dum() {
>    b::Quux& theQuux = getQuux();
>    theQuux.<M-x semantic-ia-complete-symbol-menu> => bogus completions
>}
>
>}
>}
>---foo.cpp--------------------------------------------------------
>
>That is, within dum() in foo.cpp it can't complete b::Quux members
>but instead gives me:
>
>* getQuux () : class b::Quux
>* theQuux : class b::Quux
>
>> A good way to check when you encounter an issue is with:
>> M-x semantic-analyze-current-context RET
>
>This gives me:
>
>Context Type: #<semantic-analyze-context context>
>Bounds: (129 . 129)
>Prefix: class b::Quux theQuux
>        ""
>Prefix Classes: 'function
>                'variable
>Prefix Types: 'nil
>--------
>Scope Types: namespace a {}
>             namespace c {}
>Scope: foo.hpp
>       quux.hpp
>       namespace a {}
>       namespace a {}
>       namespace b {}
>       class b::Quux getQuux ()
>       namespace c {}
>LocalVars: class b::Quux theQuux
>

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

Hi,

  Debugging your example was confusing, but I did discover that the
prototype class was getting in the way of finding the real class.  So
I changed the C++ parser to mark the prototype as such.  That still
didn't work, so I spent some time just analyzing the analyzer, moving
things around, adding comments and sections, and trying to simplify
some things based on what I'd learned recently.  Then I replaced all
the comments like "we should be smarter here", with a new
`semantic-analyze-select-best-tag' function.  When I was done, your
example worked as expected.  Huzzah!

Thanks again for the great example.

Eric

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> Your below example was excellent.  It exposed an area of namespaces
>> that wasn't yet supported.  I was able to fix the second problem in
>> semantic-c.el, and semantic-analize.el such that it worked for your
>> below example.
>>
>> If you could get the latest from CVS and let me know how it goes,
>> I would be most appreciative.
>
>The CVS version indeed worked for my example but it seems my
>example was too simple to correspond to the real case I was having
>problems with.  Here's un updated version:
  [ ... ]

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

>   Debugging your example was confusing, but I did discover that the
> prototype class was getting in the way of finding the real class.  So
> I changed the C++ parser to mark the prototype as such.  That still
> didn't work, so I spent some time just analyzing the analyzer, moving
> things around, adding comments and sections, and trying to simplify
> some things based on what I'd learned recently.  Then I replaced all
> the comments like "we should be smarter here", with a new
> `semantic-analyze-select-best-tag' function.  When I was done, your
> example worked as expected.  Huzzah!

Great work, current CVS version seems to work with my example indeed.
Unfortunately my example still seems to be insufficient to model
the problem with my real code :(

I have tried to figure out what makes them different but so far I
haven't come up with anything.  However, I see something that
puzzles me; maybe you could help me out with this.

Let's look at foo.cpp again:

---foo.cpp--------------------------------------------------------
#include "foo.hpp"
#include "quux.hpp"

namespace a {
namespace c {

void dum() {
    b::Quux& theQuux = getQuux();
    theQuux<M-x semantic-analyze-current-context>
}

}
}
---foo.cpp--------------------------------------------------------


If I invoke semantic-analyze-current-context as indicated
above, it tells me:

* (1) 

Prefix: class b::Quux rWaveformStatusModel
Prefix Classes: 'function
                'variable
--------

Now, if I add a dot after theQuux, i.e.

       theQuux.<M-x semantic-analyze-current-context>

the scope remains identical but the info at the beginning changes
to:

* (2)

Prefix: class b::Quux theQuux
        ""
Prefix Classes: 'function
                'variable
Prefix Types: class Quux {}
--------

When I do the same with my real code, the first case (without dot)
is equivalent to (1) but the second one is equivalent to this:

Prefix: "theQuux"
        ""
Prefix Classes: 'function
                'variable
--------

Semantic seems to know the type in the first case since it is
displayed after "Prefix:".  If I add the dot it somehow no longer
sees the type.  Or maybe I'm just interpreting the output
incorrectly and the existence of type after "Prefix:" doesn't
really mean much.

Are there any other functions except
semantic-analyze-current-context that I could use to get
information out of my case?  I have stared contents of
semanticdb-database-list and it looks reasonable to me but I could
easily be missing something.

-- 
Hannu

In real code, the part of the C parser that finds local variables may
be confused, though I don't know why the "." would be related.  for
example, when I use your old example with
semantic-analyze-current-context, I get:

---------
Context Type: #<semantic-analyze-context context>
Bounds: (202 . 202)
Prefix: class b::Quux theQuux
        ""
Prefix Classes: 'function
                'variable
Prefix Types: class Quux {}
--------
Scope Types: namespace a {}
             namespace c {}
Scope: quux.hpp
       foo.hpp
       namespace a {}

[ SNIP ]

       class b::Quux getQuux ()
LocalVars: class b::Quux theQuux
----------

If LocalVars were empty, or excluded your variable then it would be
unable to determine the class of Quux.

Does that seem likely?

Eric

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>>   Debugging your example was confusing, but I did discover that the
>> prototype class was getting in the way of finding the real class.  So
>> I changed the C++ parser to mark the prototype as such.  That still
>> didn't work, so I spent some time just analyzing the analyzer, moving
>> things around, adding comments and sections, and trying to simplify
>> some things based on what I'd learned recently.  Then I replaced all
>> the comments like "we should be smarter here", with a new
>> `semantic-analyze-select-best-tag' function.  When I was done, your
>> example worked as expected.  Huzzah!
>
>Great work, current CVS version seems to work with my example indeed.
>Unfortunately my example still seems to be insufficient to model
>the problem with my real code :(
>
>I have tried to figure out what makes them different but so far I
>haven't come up with anything.  However, I see something that
>puzzles me; maybe you could help me out with this.
>
>Let's look at foo.cpp again:
>
>---foo.cpp--------------------------------------------------------
>#include "foo.hpp"
>#include "quux.hpp"
>
>namespace a {
>namespace c {
>
>void dum() {
>    b::Quux& theQuux = getQuux();
>    theQuux<M-x semantic-analyze-current-context>
>}
>
>}
>}
>---foo.cpp--------------------------------------------------------
>
>
>If I invoke semantic-analyze-current-context as indicated
>above, it tells me:
>
>* (1) 
>
>Prefix: class b::Quux rWaveformStatusModel
>Prefix Classes: 'function
>                'variable
>--------
>
>Now, if I add a dot after theQuux, i.e.
>
>       theQuux.<M-x semantic-analyze-current-context>
>
>the scope remains identical but the info at the beginning changes
>to:
>
>* (2)
>
>Prefix: class b::Quux theQuux
>        ""
>Prefix Classes: 'function
>                'variable
>Prefix Types: class Quux {}
>--------
>
>When I do the same with my real code, the first case (without dot)
>is equivalent to (1) but the second one is equivalent to this:
>
>Prefix: "theQuux"
>        ""
>Prefix Classes: 'function
>                'variable
>--------
>
>Semantic seems to know the type in the first case since it is
>displayed after "Prefix:".  If I add the dot it somehow no longer
>sees the type.  Or maybe I'm just interpreting the output
>incorrectly and the existence of type after "Prefix:" doesn't
>really mean much.
>
>Are there any other functions except
>semantic-analyze-current-context that I could use to get
>information out of my case?  I have stared contents of
>semanticdb-database-list and it looks reasonable to me but I could
>easily be missing something.
>

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

> In real code, the part of the C parser that finds local variables may
> be confused, though I don't know why the "." would be related.  for
> example, when I use your old example with
> semantic-analyze-current-context, I get:
>
> ---------
> Context Type: #<semantic-analyze-context context>
> Bounds: (202 . 202)
> Prefix: class b::Quux theQuux
>         ""
> Prefix Classes: 'function
>                 'variable
> Prefix Types: class Quux {}
> --------
> Scope Types: namespace a {}
>              namespace c {}
> Scope: quux.hpp
>        foo.hpp
>        namespace a {}
>
> [ SNIP ]
>
>        class b::Quux getQuux ()
> LocalVars: class b::Quux theQuux
> ----------
>
> If LocalVars were empty, or excluded your variable then it would be
> unable to determine the class of Quux.
>
> Does that seem likely?

In my real code LocalVars includes the variable in question whether
I have "." or not.

I don't know what on earth I did but I managed to reproduce the
problem in _one Emacs session_ by altering my earlier example code
into this:

-- foo.cpp --------------------------------------------------
#include "foo.hpp"
#include "kala.hpp"

#define DUM(class, something) getQuux()

namespace a {
namespace c {

void dum() {
    b::Quux& theQuux = DUM(b::Quux, foo);
    theQuux.<completion doesn't work here>
}

}
}
-- foo.cpp --------------------------------------------------

semantic-analyze-current-context produces:

Context Type: #<semantic-analyze-context context>
Bounds: (178 . 178)
Prefix: class b::Quux theQuux
        ""
Prefix Classes: 'function
                 'variable
Prefix Types: 'nil
--------
Scope Types: namespace a {}
             namespace c {}
Scope: foo.hpp
       kala.hpp
       const DUM
       namespace a {}
       namespace a {}
       subdir/quux.hpp
       namespace c {}
       namespace b {}
       class b::Quux getQuux ()
       namespace c {}
LocalVars: class b::Quux theQuux

-- foo.hpp --------------------------------------------------
namespace a {
namespace b {

class Quux;

} // namespace b

b::Quux& getQuux();

namespace c {

class Sur {
public:
    void test() const;
};
}
} // namespace a
-- foo.hpp --------------------------------------------------

-- kala.hpp -------------------------------------------------
#include "subdir/quux.hpp"
-- kala.hpp -------------------------------------------------

-- subdir/quux.hpp ------------------------------------------
namespace a {
namespace b {

class Quux {
public:
    void kil() { }
    void kal() { }
};

}
}
-- subdir/quux.hpp ------------------------------------------

But when I started a new Emacs and loaded those files it was able
to do completion!  I wish I could figure out how to make a solid
example case :(

-- 
Hannu

>>> Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos <tiagomatos@...> seems to think that:
>Hi all,
>
>I've been for some time now trying cedet's intellisense feature (which I
>think is the only sore point in emacs) from the pre3 release to a CVS
>version from some weeks ago. Still I haven't been able to get it to work
>(maybe my hopes are too high?).
>
>First I'd like to know to what extent are the instructions at [1] still
>valid with current CVS? The answer to this could be a basis to a revamp
>of that page which I'd be happy to do myself since I find the current
>page a little bit confusing. Maybe even remove mentions to beta versions
>and pre release versions that are quite old now anyway. BTW, patches for
>the site should be against the files at [2] right?

You are right, that page should be updated to remove references to old
versions, particularly the beta versions which really aren't relevant.
The stuff under the heading "In version 2.0 beta2 or later" is still
accurate if overly brief.

What isn't listed there are all the bits and pieces needed to tune
semantic so it can do completion within a project that involves more
than one directory.  That is certainly something missing.

And yes, patches against the CVS version are best since the updating
the web site is just a "cvs up" command.

>Ok, I'll try to explain what my expectations of a _usable_ intellisense
>feature are. I'll assume only C use for now since that's what I'm most
>interested in and to keep things simple.
>
> * The setup should be brainded simple. For each project I'd like to be
>able to tell emacs to parse source files (both .c and .h including
>things like libc's headers) recursivelly begining at a set of roots.
>Even nicer if I could have some standard set and then be able to just
>extend that set for any given project (so to not always have to repeat
>things like /usr/include).

If a project uses EDE projects, or Automake, the EDE system will
automatically detect project roots.  If you need to specify the roots
yourself, customize `semanticdb-project-roots', or write a function
for `semanticdb-project-root-functions'.

Asking Emacs/semantic to parse all source files in a project can take
a long time.  I remember waiting an hour just to get through one
directory in /usr/include before deciding that was not the best
solution.

I had intended to use ebrowse for a long time to make a fast parsing
backend for semanticdb engine.  Thankfully, Joakim finally did the
research to make that happen.  See the commentary in
semanticdb-ebrowse for the basics there.

Currently missing is the "automatic" and "recursive" parts.  After
reading a bunch on this topic on Emacswiki, I've started looking into
how to make the ebrowse back end do this.  To start, I made it only
parse header files since that's all that is needed for completion.

> * Emacs should keep these databases somewhere so to not have to reindex
>things at each new run and should be smart enough to reindex files that
>have changed since last indexing [3].

Semanticdb, and semanticdb-ebrowse both do this, though ebrowse still
needs the checksumming feature to reindex on changes.

I've contemplated various options for an external database program to
try and boost the speed of lookups, but other bugs are usually more
important.

> * Then, using the current buffer's #include sentences, emacs should do
>the actual intelligent completion. By this I mean:

This is how it currently works.  See
`semanticdb-find-test-translate-path' which is what I use to debug
problems in this feature.  Also see `semanticdb-find-default-throttle'
for how to tune to your preference.

>  - I start to write something and as soon as I hit the keybindings for
>semantic-ia-complete-symbol, emacs should complete as many characters as
>it possibly can given the various available possible completions to the
>written prefix, much like bash, like so:
>
>	gtk_win[hit keybinding]
>
>since 'gtk_win' can only lead to (I'm not sure this is really true but
>it illustrates my point)
>
>	gtk_window_
>
>it should add the characters 'dow_' and stop here since there are a lot
>of symbols in gtk that start with this prefix. Then on a second
>keybinding hit it should actually try to display the possible
>completions using the standard emacs' completions special window (I
>don't like dropdown menus like visual studio or eclipse but this could
>be configurable for those who do). This is all pretty much like bash
>would behave... only it's "intelligent" from the C point of view.
>
>The same would apply to a variable 'foo' of type 'struct Foo' with
>fields 'bar' and 'bat':
>
>	foo.[hit keybinding]
>
>leads to
>
>	foo.ba
>
>either accessed with '.' or '->' if 'foo' was a pointer. And so on and
>so forth for the various C constructions.
>
>I'm almost certain CEDET can't provide an experience like this yet and
>maybe I'm being too demanding (I'd love to control a computer with my
>mind ;-). Anyway I'd like a factual answer regarding what CEDET can do
>today and what are the plans for the future. Would any of this be
>feasible? Does it even make sense?

I recently (to CVS) added the command `semantic-complete-self-insert'
which you could bind to . or > in C/C++.  The idea is it will go into
"completion mode" so SPC and TAB act as in a minibuffer, and
completions show up in a tooltip.

At the moment, this happens in `global-semantic-idle-completions-mode'
as a timer, but over time I've been finding that more annoying than
helpful.

I don't know what the ideal interface/keybindings/whatever are, but
the basics are there waiting to be bound to a key.

The other aspect is the "smart" part, or figuring out where the
completions come from.  What you describe is what the system was
designed to do, but it has some problems.  The problems usually lie in
one of two places:

1) semantic can't find the header with the definition you want.
2) semantic's context analyzer gets confused.

As far as I know, it is just a matter of finding and debugging these
problems.

>I should note that I don't think I have the skills to implement this (my
>emacs lisp knowledge is very basic and I don't have experience with
>large projects) but I'd surely help as far as I could, learning in the
>process :-)

If you know how to bind keys, collect stack traces, and make small
examples that "don't work as expected", then please try out some of
the above and, as you suggested, update the web page to assist others
with what you learn!

Sadly, statements like "I haven't been able to get it to work" are
common, and don't help me solve problems.

>Thanks for listening,
>
>Rui
>
>[1] http://cedet.sourceforge.net/intellisense.shtml
>[2] http://cedet.cvs.sourceforge.net/cedet/cedet/www/
>
>[3] As a sidenote I have been thinking that maybe even better for
>performance and code reuse reasons emacs should use a helper process to
>to these things. More: these days with indexers like tracker
>[http://www.gnome.org/projects/tracker/] that helper process could spawn
>a dedicate tracker daemon just to handle all this indexing and database
>maintnance. Obviously indexing rules to generate correct semantic
>information for each language would have to be added to tracker.

Hmm, I'd been thinking about using a generic indexer (common for
search engines, help browsers, etc) to provide cscope like features
for any language in a generic way.  One was installed where I work
recently for this purpose, and I'll pass judgment on it after I get to
use it for a while.  I suspect it will have problems with namespaces,
classes, and fields and not be very useful.

Hope this was helpful.
Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

>>> David Hansen <david.hansen@...> seems to think that:
>Hello,
>
>to reproduce this enable `global-semantic-show-unmatched-syntax-mode'
>and open some_file.lisp.
>
>(defun foo ()
>  #\A)
>
>gets highlighted with `semantic-unmatched-syntax-face'.  Note that
>this doesn't seem to be limited to the '\' reader macro but also
>some others i tried.  See "2.4.8 Sharpsign" in the Hyper Spec for a
>list of valid reader macros.
  [ ... ]


Hi,

  The semantic Lisp parser uses Emacs' `read' to do the parsing.  In
Emacs, if you do:

M-: (read "(defun foo () #\A)")

  it will throw an error.

  So basically, to get this to work for Lisp (not Emacs Lisp,) we would
need to write a new parser.  It would likely be similar to the scheme
parser which is pretty simple.

  I'll add this to my todo list, but I'm not sure when I'll get to it
since I don't usually program in Common Lisp.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

>>> David Hansen <david.hansen@...> seems to think that:
>>(defun foo ()
>>  #\A)
>>
>>gets highlighted with `semantic-unmatched-syntax-face'.  Note
>>that
>>this doesn't seem to be limited to the '\' reader macro but also
>>some others i tried.  See "2.4.8 Sharpsign" in the Hyper Spec for
>>a
...
>   The semantic Lisp parser uses Emacs' `read' to do the parsing.
>>In
...
>   So basically, to get this to work for Lisp (not Emacs Lisp,) we
>>would
> need to write a new parser.  It would likely be similar to the
>>scheme
> parser which is pretty simple.

You probably know this well but, as a remainder, unlike in Scheme
or Emacs Lisp, reader in Common Lisp is programmable.  Of course,
that doesn't mean that a better-than-current parser that could
handle the default syntax and maybe a few common ways to extend the
syntax would be a bad thing.  That's really all anyone can ask.
Maybe it could also be used as a basis for a cl-indent.el
replacement.

Then again I am surprised that someone has even tried to use
Semantic with CL.  Some of the most important functionality (in my
opinion; completion, jumping to definitions/callers/etc) provided
by CEDET tools is already provided by SLIME (the currently "hip"
package that integrates CL implementations to Emacs) in a way
specific to CL by talking to the external CL process.  I don't know
if Semantic could somehow interface to SLIME (I suspect this would
correspond to whatever you guys have been talking about Java and
beanshell stuff recently, although I haven't paid much attention to
that so this is wild speculation) but either way I doubt that there
is much interest to this sort of marriage (that's just my
suspicion, I can't speak for other CL developers).

Personally I only wish that some day Semantic would provide for C++
some of the functionality SLIME provides for Common Lisp (obviously
not interactivity which is SLIME's main point but at least working
completion and jump to definition/callers/etc based on static
analysis/parsing).

--
Hannu

On Wed, 21 Feb 2007 17:45:09 +0200 Hannu Koivisto wrote:

> Then again I am surprised that someone has even tried to use
> Semantic with CL.  Some of the most important functionality (in my
> opinion; completion, jumping to definitions/callers/etc) provided
> by CEDET tools is already provided by SLIME (the currently "hip"
> package that integrates CL implementations to Emacs) in a way
> specific to CL by talking to the external CL process.

It happened more or less by accident.  I played around with cedet
again and turned on a lot of stuff globally and then opened a .lisp
file.

David

"Eric M. Ludlam" <eric@...> writes:

>>(defun foo ()
>>  #\A)
>>
>>gets highlighted with `semantic-unmatched-syntax-face'.  Note that
>>this doesn't seem to be limited to the '\' reader macro but also
>>some others i tried.  See "2.4.8 Sharpsign" in the Hyper Spec for a
...
>   The semantic Lisp parser uses Emacs' `read' to do the parsing.  In
...
>   So basically, to get this to work for Lisp (not Emacs Lisp,) we would
> need to write a new parser.  It would likely be similar to the scheme
> parser which is pretty simple.

You probably know this well but, as a remainder, unlike in Scheme
or Emacs Lisp, reader in Common Lisp is programmable.  Of course,
that doesn't mean that a better-than-current parser that could
handle the default syntax and maybe a few common ways to extend the
syntax would be a bad thing.  That's really all anyone can ask.
Maybe it could also be used as a basis for a cl-indent.el
replacement.

Then again I am surprised that someone has even tried to use
Semantic with CL.  Some of the most important functionality (in my
opinion; completion, jumping to definitions/callers/etc) provided
by CEDET tools is already provided by SLIME (the currently "hip"
package that integrates CL implementations to Emacs) in a way
specific to CL by talking to the external CL process.  I don't know
if Semantic could somehow interface to SLIME (I suspect this would
correspond to whatever you guys have been talking about Java and
beanshell stuff recently, although I haven't paid much attention to
that so this is wild speculation) but either way I doubt that there
is much interest to this sort of marriage (that's just my
suspicion, I can't speak for other CL developers).

Personally I only wish that some day Semantic would provide for C++
some of the functionality SLIME provides for Common Lisp (obviously
not interactivity which is SLIME's main point but at least working
completion and jump to definition/callers/etc based on static
analysis/parsing).

-- 
Hannu

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>>>> David Hansen <david.hansen@...> seems to think that:
>>>(defun foo ()
>>>  #\A)
>>>
>>>gets highlighted with `semantic-unmatched-syntax-face'.  Note
>>>that
>>>this doesn't seem to be limited to the '\' reader macro but also
>>>some others i tried.  See "2.4.8 Sharpsign" in the Hyper Spec for
>>>a
>...
>>   The semantic Lisp parser uses Emacs' `read' to do the parsing.
>>>In
>...
>>   So basically, to get this to work for Lisp (not Emacs Lisp,) we
>>>would
>> need to write a new parser.  It would likely be similar to the
>>>scheme
>> parser which is pretty simple.
>
>You probably know this well but, as a remainder, unlike in Scheme
>or Emacs Lisp, reader in Common Lisp is programmable.  Of course,
>that doesn't mean that a better-than-current parser that could
>handle the default syntax and maybe a few common ways to extend the
>syntax would be a bad thing.  That's really all anyone can ask.
>Maybe it could also be used as a basis for a cl-indent.el
>replacement.

The cedet parsers are generally targeted at tagging information so
there isn't much detail inside function bodies where good indentation
is needed.  Adding that type support is something I'd like to see
happen someday though for a wide range of other types of tools.

>Then again I am surprised that someone has even tried to use
>Semantic with CL.  Some of the most important functionality (in my
>opinion; completion, jumping to definitions/callers/etc) provided
>by CEDET tools is already provided by SLIME (the currently "hip"
>package that integrates CL implementations to Emacs) in a way
>specific to CL by talking to the external CL process.  I don't know
>if Semantic could somehow interface to SLIME (I suspect this would
>correspond to whatever you guys have been talking about Java and
>beanshell stuff recently, although I haven't paid much attention to
>that so this is wild speculation) but either way I doubt that there
>is much interest to this sort of marriage (that's just my
>suspicion, I can't speak for other CL developers).

You can chop semantic into 3 layers.  There is the middle layer that
defines what a TAG looks like, manages tags, and APIs for saving,
restoring, and searching tags.  There are also tools for creating
class trees and attempting to analyze a particular bit of code.

This layer depends on the parser layer.  Parsers can be written in by
(bovine) format or wy (wisent) format which are Semantic's built in
aids for writing parsers.  You can also write your own using any
technique you want, such as using regexps, like the texinfo and html
parsers.

Lastly, there are the applications that sit on top of the semantic
APIs, many of which come with semantic.

The basic idea is that you can take some new language, define a parser
using any mechanism you want, override a few language specific
functions, and possibly write a backend for a system database of tags,
and have all the semantic applications work for that application.  On
the other side, if you want to write a new application for you
language, if your language is supported, you can write it against the
Semantic API, and know it will work pretty well for any language
semantic eventually supports.

My theory has always been that the more languages supported by
cedet/semantic, the more folks will use the core parts of cedet, and
over time, the better the applications that sit on it will be for all
languages, not just for the languages that hard-core Emacs hackers use.

>Personally I only wish that some day Semantic would provide for C++
>some of the functionality SLIME provides for Common Lisp (obviously
>not interactivity which is SLIME's main point but at least working
>completion and jump to definition/callers/etc based on static
>analysis/parsing).
  [ ... ]

Me too.  It's been getting better as time marches on and as I,
personally, learn more C++.  The CVS version supports much more than
the currently released version (1.0pre3), and the new ebrowse DB
support makes parsing lots of header files for the system, or your
project a quick process.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

Hi,

  I followed your sample, and still can't repro the problem.  I
suspect semanticdb is digging up some symbols from your project roots
which you list below.

  What you could do is go to semantic-complete.el and look for the
function `semantic-complete-inline-force-display'.  Remove the
condition-case.  Then do:

M-x eval-current-buffer RET  

to improve what the stack will say, then

M-x toggle-debug-on-error RET

 and repro the problem.  

That stack should help us identify the specific problem.

If there are a few obvious variables try:

e variable-name

from the stack buffer to print the value of various variables.

Thanks!
Eric

>>> David Hansen <david.hansen@...> seems to think that:
>On Mon, 5 Feb 2007 20:25:34 -0500 Eric M. Ludlam wrote:
>
>> I'm not sure about the idle problem you mention.  It was working ok
>> for me in that case.
>
>OK, it's still there.  Here is how to reproduce (emacs-version
>"22.0.93.1", cedet updated about 10h ago):
>
>$ emacs -Q
>
>eval in *scratch* (fix the paths if needed):
>
>(defun dh-map-files (function directory &optional full match recursive)
>    (mapc #'(lambda (file)
>              (when (and recursive (file-directory-p file))
>                (dh-map-files function file full match recursive))
>              (when (string-match match file)
>                (funcall function file)))
>          (directory-files directory full match)))
>
>(eval-and-compile (load-file "~/.elisp/cedet/common/cedet.el"))
>(semantic-load-enable-gaudy-code-helpers)
>
>(setq semanticdb-default-save-directory "~/.emacs.d/semantic/")
>
>(flet ((add-to-project-roots (file)
>         (when (file-directory-p file)
>           (add-to-list 'semanticdb-project-roots file))))
>  (dh-map-files #'add-to-project-roots "~/projects/" t "^[^.]")
>  (dh-map-files #'add-to-project-roots "~/cvs-src/" t "^[^.]"))
>
>open some emacs lisp file (empty or not), type "(wh" and wait some
>time until the completions show up and you get the message (note
>that the offending code is probably wrapped in a `condition-case' or
>similar):
>
>Bug Showing Completions: (wrong-type-argument integerp nil)
>
>David
  [ ... ]

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org