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@...:
> 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 (孔直秋)
|