Hi,

1. Thank you very much for your reply, now i know why it did not work for me and i've changed my coding style :)

Another issue about semantic completions is like this:

I found the position of "using namespace ***" will effect the completions, for example, I have a simple bread.hpp which writes like this:

#ifndef BREAD_H
#define BREAD_H

namespace bread_name{
    class bread
    {
    public:
        void geta();
    private:
        int m_a;
        int m_b;
    };
}

#endif

and i write like this in panda.cpp

#include "bread.hpp"
using namespace bread_name;

namespace panda{

    int func()
    {
        bread test;
        test.
        return 0;
    }
}

Now i can get completions using semantic, but if i moved the "using namespace bread_name" inside the declaration of namespace panda, just like this:

#include "bread.hpp"

namespace panda{

    using namespace bread_name;
    int func()
    {
        bread test;
        test.
        return 0;
    }
}

The completions will not show up. Since the codes above can be compiled, i think maybe there's something wrong with semantic's analyzing?

2. Sometimes, even if 'semantic-analyze-debug-assist' could show me all the possible completions, 'semantic-ia-complete-symbol-menu' might not show all. For example, after i added two other functions to bread.hpp:

int set(int, int);
void test();

I got back to panda.cpp and try completions, only geta() and set(int, int) can be got, but when i try 'semantic-analyze-debug-assit', i was told:

Possible completions are:
  int geta ()
  void set (int,int)
  void test (int haha)


Known members of bread:
  public
  int geta ()
  void set (int,int)
  void test (int haha)
  private
  int m_a
  int m_b

It seems that all the members are got by semantic. But this infomation can be losed after i closed emacs and reopen it, which means, after i reopen panda.cpp, i just find that even semantic-analyze-debug-assist can not get the possible completions. I need to manually 'C-u M-x bovinate' to make them work.

What's more, after i use 'C-u M-x bovinate' to make the completions menu work properly, i found function overloading may not be processed. That happened after i added another version of set:

void set(float, char);

I can see it via 'semantic-analyze-debug-assist' but it's not in completions menu. It seems the newer one is hidden by the older one.

3. I'm confused with "semantic-idle-scheduler-work-idle-time" and "semantic-idle-scheduler-idle-time".
As what i thought before, i think the formmer is the one which controls the analyzing interval, which means, if i set this as 60, then semantic will analyze my codes every 60s. And speak of the latter, i thought it controls how long i need to wait till the summary of current context will show in the minibuffer. But now i'm confused because:

1) what does idle mean? does it mean, if i type whithout stop, semantic will not do anything?

2) i've set the idle-summary-function as "semantic-format-tag-uml-prototype", but i found the info showed after i stop a while on some function is different with the one showed up when i manually tirgger 'semantic-ia-show-summary', so idle-summary-function controls which one?

3) even i set semantic-idle-scheduler-idle-time as 1s, i found the summary of current context (for example, a funciton) will not always show up. Since i've set semantic-idle-scheduler-work-idle-time as 5 seconds, does the two conflict with each other?

Thank you very much, for your great job for cedet, it really helps a lot when i'm coding. And i hope it will be better :)

On Tue, Nov 25, 2008 at 12:02 AM, Eric M. Ludlam <eric@siege-engine.com> wrote:
Hi,

 I now know more about this problem.

 The main issue is that bread.cpp is incomplete.  When main() is
parsed, semantic can't know where it really ends.  If the idle
scheduler goes off, this is detected, and the buffer is put into an
"unparsable" state, and no more incremental parsing will occur until
you type stuff.

 If instead you use M-x bovinate, then the incomplete syntax is
assumed to have an "end" at the end of the buffer.  This is the wrong
answer, of course, as Emacs can't know that, but it will get you
started, and has a side effect of making this example work.

 The idle scheduler behaves as it does because it will disable slow
stuff while you are hacking up new code.  Once you are done, it will
catch up, and enable this sort of thing again.  If it did not, and you
edited the first of say, 100 fcns, then if you type

if() {
 foo.

it would wipe out everything it knows about fcns showing up after that
line, and the completion would fail.  Thus, once you finish typing the
curly } for the close of the if, it will then get the new state of the
current function refreshed in the tag list.

The other style is used if a buffer is first brought up.  It will just
do it's best to get you going.

As such, this problem isn't really fixable.

 This issue needs you to subtly change how you type.  When creating a
new file, type like this:

#include "whatever.h"

main () {
}

then after you do that, go back and change it to:

main () {
   bread haha;
   haha.
}

and things will work as predicted.  I changed the way I type a long
time ago, and that's why I don't see this issue.


--
Zhiqiu Kong (孔直秋)