Hi, Eric.
I use smart completion in my C and C++ code, it is very cool.
Now I need to write python code, but I found semantic can only get the "top
level" variable and function's name to complete. If I define a python
function in a class, I can not get its completion. It is because semantic
can not support or something of my configuration is wrong?
YuPeng

On 24/03/2009, at 10:04 PM, Eric M. Ludlam wrote:
>> In toplevel form:
>> cogre-utest.el:33:1:Error: Non-Mac frame used
>> make: *** [tests] Error 1
>>
>>
>> Looks like an emacs bug, but just wondering if anyone else has seen
>> it?
> [ ... ]
>
> I don't have this problem. I looked for code that would execute on a
> compile here, but I don't see anything there either.
>
> I wonder if the same problem would arise if you loaded cogre-utest.el
> in running Emacs with toggle-debug-on-error active?
Hmm, it seems to be related to the presence of a frame. If I start
emacs using -nw I get the error, but not otherwise. I'll raise it on
the carbon-emacs list...

Hi,
It thinks that you are calling "member", and that member's first
argument is of type Xy. Az Xy is not defined anywhere, it can't find
any data types to match, thus no completions.
If you use the senator completion, it will use a simplified completer
as a backup, and likely hit your case.
This is a class of problem I've had my eye on fixing for a while. The
local context parser can't distinguish the code block from the
declaration part of the function. As such, it treats the whole block
as code.
My plan is to add a 'code tag class, and all functions would have a
'code block that can be treated differently. This will require
updates to all the various parsers, and a lot of miscellaneous logic
changes throughout CEDET to take this new tag class into account in a
rational way.
This update is needed for my round-trip code generation plans also, so
it will get done eventually.
Eric
>>> Hannu Koivisto <azure@...> seems to think that:
>Greetings,
>
>Is it a known problem that in...
>
>--- foo.cpp ---
>class Foo
>{
> struct Xyzzy {
> int bar;
> };
>
> int member(Xy<complete>) {
> return 0;
> }
>};
>--- end of foo.cpp ---
>
>...Semantic cannot complete Xy to Xyzzy?
>
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

A good thought.
I think there are several "do-something-other-window" type functions
out there. The senator feature, and `semantic-ia-fast-jump' should
probably follow whatever the regular Emacs model for it is.
If such a feature already exists, I didn't write it. Using those
types of features isn't in my finger-memory when I hack in Emacs.
Note: You seem to not be subscribed to cedet-devel.
Eric
>>> <klaus.berndl@...> seems to think that:
>Hi,
>=20
>this function works great, at least with elisp - others i have not =
>tested...
>=20
>But: IMHO it would great if there would be a similar command =
>senator-complete-display which would not perform a switch-to-buffer but =
>instead a call of display-buffer, so the definition of the tag would =
>only displayed in another window but not jumped to that. IMHO it is =
>often sufficient to take a look to the tag-definition...
>=20
>What do you think - maybe an optional argument JUST-DISPLAY for the =
>command senator-complete-jump which does exactly this?!
>=20
>Thoughts? Or have i overlooked something and there is already a =
>mechanism for that what i want?
>=20
>Ciao,
>Klaus
[ ... ]
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>>>>> Hannu Koivisto <azure@...> seems to think that:
>
>>>int foo()
>>>{
>>> int kala;
>>> l<M-x semantic-ia-complete-symbol RET>
>>> int lahna;
>>>}
>>>
>>>...semantic completes lahna even though it is not a valid
>>>completion.
>>
>> Interesting. Local variables are captured withing a "scope". That
>> way if you move the cursor in the scope, you can recycle the old
>> data. As such, there is a performance trade-off.
>>
>> What do you think?
>
>While I usually like the "first correct, then fast" way, I would
>agree that this is probably not the most important correctness
>issue :) I noticed it sort of around the corner (with speedbar
>analyzer) -- the example above was artificial -- and I suspected
>this might end up to the "known issues" list, if there is one.
>(Unfortunately) I have seen C++ code where some local variable
>definitions were so far apart that if this worked correctly, it
>might be helpful, but I hope such situations are rare.
The scope object has a couple levels of reset. If the incremental
parser changes the list of includes, for example, the whole thing is
reset. If the cursor moves around inside a single tag, then the local
variables are reset. If the cursor moves into a different tag, then
everything is reset.
In researching this answer, I suspect that trimming back the local
variables list would be ok as it appears that gets redone for cursor
movements already, so no loss. Someone just needs to add that
behavior into the local variable parser somehow. (That would be
`semantic-get-local-variables' if someone wants to give it a try.)
>If I put my programmer hat on, the performance trade-off comment
>is interesting, though. As far as I can see, if I rewrite the
>code like this...
>
>int foo()
>{
> int kala;
> l<...>
> {
> int lahna;
> }
>}
>
>...I get no false completions. Should I now see some real
>performance problem (even if the code was more complex than that
>example)? Why can't one 'recycle the old data' when one moves to
>another scope? Don't you have this same issue when you move the
>cursor from, say, one method to another? I wouldn't want
>performance problems in that case either and intuitively that feels
>like a bigger change.
I don't know if it is a performance "problem" at this point, though I
suppose a fabulously long and complex function could be problematic.
I just go out of my way to cache data as much as I can and have as
many lazy reset options as possible.
>>>Also, is it a known issue that you need to type at least one
>>>character before you can list completions? For example, in the
>>>above scenario, if I hadn't typed "l" before using
>>>semantic-ia-complete-symbol, I wouldn't have gotten any completions.
>>
>> Yes. This is to dodge the 10000 possible completions problem.
>
>Hmm. Presumably the problem with that is generating the
>completions, not displaying them? Just out of curiosity, can you
I don't know. I didn't profile stuff back when I disabled it, though
later experience shows that dumping huge lists of strings into a
display buffer is usually slower than calculating them.
>ask Semantic APIs for completions incrementally by scope,
>i.e. something like "give me completions within local variables"
>(I'm simplifying that there is only one local variable scope),
>"give me completions within class members", "give me completions in
>the innermost namespace" etc?
That's a cool idea, though more of an option for the tool that
performs the completion. It is possible to get the local scope, and
the local typecache and do this work without the context analyzer.
The analyzer API is a one-shot deal with only one level.
While a blank command is a bit of a stretch for auto-generating some
code, I know I'd love to solve problems such as:
const int ma=1, mb=2;
int foo(int a) {
myfcn(-!-
and some universal completion key would fall to a mode where it knows
that the first arg of myfcn is "int", and the most likely candidate is
"a", and just do it, instead of relying on the really complicated
completion system. The next most likely might be ma, or mb, because
those variables are nearby.
For SRecode, it gets more interesting. In place of "myfcn" above, if
the user asked to create a 'for' loop, it might guess that you'd want
to loop from 0 to a. Or perhaps there is a std::vector and you'd want
to generate some iterators for it, and loop over those.
There are many interesting heuristics that would be fun to explore.
>Also, if you have
>
>-- foo.hpp --
>
>class Foo {
>...
>};
>
>-- bar.hpp --
>
>#include "foo.hpp"
>
>class Bar : public Foo {
> int baz();
> ...
>};
>
>int Bar::baz()
>{
> abc<complete>
>}
>
>----
>
>Can you ask Semantic if it _should_ know all applicable Bar members
>starting with abc? Which I believe in this case would translate to
>"do you know Foo?" which again depends on if foo.hpp has been
>parsed, although naturally you can't know if parsing foo.hpp will
>make Foo known until you actually parse it.
In this case, asking for completions will force "foo.hpp" to be
parsed, and to contribute to the completions list. This answer to
your question "do you know Foo?" is in the scope, which would list
Foo as an option.
Use
M-x semantic-calculate-scope RET
to find out what it knows.
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

>>> Hannu Koivisto <azure@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>>>>> Hannu Koivisto <azure@...> seems to think that:
>>>Greetings,
>> [ ... ]
>>>
>>>Aside of the completions issue, it would be nice if
>>>semantic-speedbar-analysis always displayed current context
>>>(typically namespaces and method in C++ code) and local variables.
>>>Currently it doesn't seem to display anything except the file name
>>>unless you are in a situation in which it displays completions as
>>>well.
>>
>> I checked in a change to do this.
>
>Sweet, it's much more "stable" now, thanks!
>
Indeed, I hadn't used that tool in quite a while. I'm not sure what
changed since I had last used it, but all that flickering and mystic
point movement was really annoying, so I fixed that a while after
solving the first problem. Hopefully it will remain stable.
Klaus has updated ECB with similar code fixes as well, so ECB fans
should check that out too. (I'd guess it is in ECB CVS)
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> Hannu Koivisto <azure@...> seems to think that:
>>Greetings,
> [ ... ]
>>
>>Aside of the completions issue, it would be nice if
>>semantic-speedbar-analysis always displayed current context
>>(typically namespaces and method in C++ code) and local variables.
>>Currently it doesn't seem to display anything except the file name
>>unless you are in a situation in which it displays completions as
>>well.
>
> I checked in a change to do this.
Sweet, it's much more "stable" now, thanks!
--
Hannu

"Eric M. Ludlam" <eric@...> writes:
>>>> Hannu Koivisto <azure@...> seems to think that:
>>int foo()
>>{
>> int kala;
>> l<M-x semantic-ia-complete-symbol RET>
>> int lahna;
>>}
>>
>>...semantic completes lahna even though it is not a valid
>>completion.
>
> Interesting. Local variables are captured withing a "scope". That
> way if you move the cursor in the scope, you can recycle the old
> data. As such, there is a performance trade-off.
>
> What do you think?
While I usually like the "first correct, then fast" way, I would
agree that this is probably not the most important correctness
issue :) I noticed it sort of around the corner (with speedbar
analyzer) -- the example above was artificial -- and I suspected
this might end up to the "known issues" list, if there is one.
(Unfortunately) I have seen C++ code where some local variable
definitions were so far apart that if this worked correctly, it
might be helpful, but I hope such situations are rare.
If I put my programmer hat on, the performance trade-off comment
is interesting, though. As far as I can see, if I rewrite the
code like this...
int foo()
{
int kala;
l<...>
{
int lahna;
}
}
...I get no false completions. Should I now see some real
performance problem (even if the code was more complex than that
example)? Why can't one 'recycle the old data' when one moves to
another scope? Don't you have this same issue when you move the
cursor from, say, one method to another? I wouldn't want
performance problems in that case either and intuitively that feels
like a bigger change.
>>Also, is it a known issue that you need to type at least one
>>character before you can list completions? For example, in the
>>above scenario, if I hadn't typed "l" before using
>>semantic-ia-complete-symbol, I wouldn't have gotten any completions.
>
> Yes. This is to dodge the 10000 possible completions problem.
Hmm. Presumably the problem with that is generating the
completions, not displaying them? Just out of curiosity, can you
ask Semantic APIs for completions incrementally by scope,
i.e. something like "give me completions within local variables"
(I'm simplifying that there is only one local variable scope),
"give me completions within class members", "give me completions in
the innermost namespace" etc?
Also, if you have
-- foo.hpp --
class Foo {
...
};
-- bar.hpp --
#include "foo.hpp"
class Bar : public Foo {
int baz();
...
};
int Bar::baz()
{
abc<complete>
}
----
Can you ask Semantic if it _should_ know all applicable Bar members
starting with abc? Which I believe in this case would translate to
"do you know Foo?" which again depends on if foo.hpp has been
parsed, although naturally you can't know if parsing foo.hpp will
make Foo known until you actually parse it.
--
Hannu

>>> Sudong Lei <leisudong@...> seems to think that:
>--001636e9132df8ca7f0465bf4691
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>
>same problem when encounter a macro "_GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)",
>and it just print a "semantic-lex-spp-token-macro-to-macro-stream: End of
>buffer", I don't know how to get more debug message.
Hi,
The parsing change didn't handle the __ in the name. That should be fixed now.
>I'm use a test code like this:
>
>#include <iostream>
>using namespace std;
>int main()
>{
>cout::<semantic-complete-analyze-inline>
>}
>
I don't have that version of those headers, but my experience
indicates that this ought to work now. I'd need to get the updated
glib to really test it out.
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

same problem when encounter a macro "_GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)",
and it just print a "semantic-lex-spp-token-macro-to-macro-stream: End of
buffer", I don't know how to get more debug message.
I'm use a test code like this:
#include <iostream>
using namespace std;
int main()
{
cout::<semantic-complete-analyze-inline>
}
2009/3/22 Eric M. Ludlam <eric@...>
> >>> Sudong Lei <leisudong@...> seems to think that:
> >excuse my bad english.
> >I am using Gentoo ~x86, gcc 4.3.3. when I open the system header file
> >"iostream" and do "M-x bovinate", it print this message in *Messages*
> buffer
> >(also in minibuffer):
> >
> >semantic-lex-spp-token-macro-to-macro-stream: End of buffer
> >End of buffer
> >
> >it seems, when encounter the macro "_GLIBCXX_BEGIN_NAMESPACE(std)", this
> >problem will appear. from now on, I don't know why.
>
>
> I was able to build a solution for _GLIBCXX_BEGIN_NAMESPACE and
> _GLIBCXX_BEGIN_NESTED_NAMESPACE today. It only works for these
> special macros though. Custom macros such as:
>
> #define MY_NAMESPACE(foo) namespace foo {
>
> will still not work. For these special things that are part of GLIBC,
> however, things should start working.
>
> The change was a bit of a hack, so if anyone discovers some new
> problems from this, let me know.
>
> Thanks
> Eric
>
> --
> Eric Ludlam: eric@...
> Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net
>

>>> Sudong Lei <leisudong@...> seems to think that:
>excuse my bad english.
>I am using Gentoo ~x86, gcc 4.3.3. when I open the system header file
>"iostream" and do "M-x bovinate", it print this message in *Messages* buffer
>(also in minibuffer):
>
>semantic-lex-spp-token-macro-to-macro-stream: End of buffer
>End of buffer
>
>it seems, when encounter the macro "_GLIBCXX_BEGIN_NAMESPACE(std)", this
>problem will appear. from now on, I don't know why.
I was able to build a solution for _GLIBCXX_BEGIN_NAMESPACE and
_GLIBCXX_BEGIN_NESTED_NAMESPACE today. It only works for these
special macros though. Custom macros such as:
#define MY_NAMESPACE(foo) namespace foo {
will still not work. For these special things that are part of GLIBC,
however, things should start working.
The change was a bit of a hack, so if anyone discovers some new
problems from this, let me know.
Thanks
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

>>> Hannu Koivisto <azure@...> seems to think that:
>Greetings,
[ ... ]
>
>Aside of the completions issue, it would be nice if
>semantic-speedbar-analysis always displayed current context
>(typically namespaces and method in C++ code) and local variables.
>Currently it doesn't seem to display anything except the file name
>unless you are in a situation in which it displays completions as
>well.
I checked in a change to do this.
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

>>> Hannu Koivisto <azure@...> seems to think that:
>Greetings,
>
>In this C++ scenario...
>
>int foo()
>{
> int kala;
> l<M-x semantic-ia-complete-symbol RET>
> int lahna;
>}
>
>...semantic completes lahna even though it is not a valid
>completion.
Interesting. Local variables are captured withing a "scope". That
way if you move the cursor in the scope, you can recycle the old
data. As such, there is a performance trade-off.
What do you think?
>Also, is it a known issue that you need to type at least one
>character before you can list completions? For example, in the
>above scenario, if I hadn't typed "l" before using
>semantic-ia-complete-symbol, I wouldn't have gotten any completions.
Yes. This is to dodge the 10000 possible completions problem.
>Also, semantic-speedbar-analysis doesn't show any information until
>I have typed something.
>
>Aside of the completions issue, it would be nice if
>semantic-speedbar-analysis always displayed current context
>(typically namespaces and method in C++ code) and local variables.
>Currently it doesn't seem to display anything except the file name
>unless you are in a situation in which it displays completions as
>well.
That's a good idea.
The completion system cuts out early as an optimization for the timer
that shows the syntax of the symbol under point.
I fixed something related to this recently based on a question from
Klaus who was working on ECB. I think Klaus is working on ECB windows
similar to the speedbar analysis mode, but he is extracting the scope
information directly instead of waiting for possible completions to be
available.
This seems like something the speedbar tool could do also, though long
term I would prefer to rely on tools like ECB which has much nicer
usability and design.
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Greetings,
In this C++ scenario...
int foo()
{
int kala;
l<M-x semantic-ia-complete-symbol RET>
int lahna;
}
...semantic completes lahna even though it is not a valid
completion.
Also, is it a known issue that you need to type at least one
character before you can list completions? For example, in the
above scenario, if I hadn't typed "l" before using
semantic-ia-complete-symbol, I wouldn't have gotten any completions.
Also, semantic-speedbar-analysis doesn't show any information until
I have typed something.
Aside of the completions issue, it would be nice if
semantic-speedbar-analysis always displayed current context
(typically namespaces and method in C++ code) and local variables.
Currently it doesn't seem to display anything except the file name
unless you are in a situation in which it displays completions as
well.
--
Hannu

>>> Alex Ott <alexott@...> seems to think that:
>Hello
>
>I found one problem with senator copy/yank tag
>
>I have function with following declaration:
>
>inline void Class::ParseRecordHeader(const unsigned char* buf, uint8_t& recVer,
> uint16_t& recInstance, uint16_t& recType,
> uint32_t& recLen) {
>...
>}
>
>I copy it with C-c , M-w, and want to insert declaration into header file.
>I do C-c , C-y, but i get following code with references omitted
>
>inline void ParseRecordHeader (const unsigned char* buf,
> uint8_t recVer,uint16_t recInstance,
> uint16_t recType,uint32_t recLen)
>
>
Hi,
That bug is probably in semantic-format-tag-prototype. I haven't
tweaked that in a long time, and I'm pretty sure capturing references
information in the tag was done after. It may be an easy tweak. I
won't be able to get to it till later this weekend.
My long term goal is to convert *some* of the semantic-format-*
functions to SRecode, which was really designed for this purpose,
though I'm not sure it is worth it for all cases since the overhead
can be high.
At a minimum, I'd like to use SRecode for this foreign tag insert
feature. SRecode is set up well for capturing where you are in a
file, and choosing the right template to use when performing an
expansion.
Have fun
Eric
--
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net