Hi Eric,

>There are two functions so that the default value in the input arg can be
>different. They both are asking the same basic question "where is some symbol
>being used", but semantic-symref asks "where is the tag I am in used", and the
>other asks "where is the symbol under point used", which are different. That way
>you can bind two different keys, and not type in what you want to look for,
>saving typing.

Thanks for explaining more on this, now I understand  your intention of having the two commands, that makes sense.

>This implies that r and s arguments are not mutually exclusive, which is good
>to know. Your patch also seems reasonable, so I don't see why it cannot be the
>default.

This seems to be working, however I haven't done enough testing yet, so I'm not sure whether this will work in all the situations, especially in the case that I know very little about 'GNU Global'. Another "safer" approach is to have one of the two commands pass a different argument, (e.g., texttype='tag?) so that 'cedet-gnu-global-search' will be able to differentiate the two kind of request and handle them differently.

>This is a classic problem with simple tagging utilities. Simple taggers are
>pretty good to find lots of references, but you need a full up analysis tool to
>throw out locations that match by text, by not by context.

Good to know that this is a classic problem with simple tagging utilities, saved me sometime trying to find out something that never existed. 

>Right now semantic symref could do this, but that last step wasn't implemented.
>In semantic-symref-result-get-tags there is an opportunity to filter out the
>bad matches, but the input (detailed info about the tag being searched for) and
>and filter need to be written.

It will be amazing if semantic can handle this. Hopefully this feature will be available in the near future and thank you so much for creating cedet which is wonderful.

>The implementation, of analyzing every hit, would also be very slow. Another
>option is to modify semantic-symref-list mode to add a "smart filter" option to
>post process the list. That way you can filter only if it matters.

This could become a temporary workaround, could you be more specific?

Thanks,

York


On Tue, Mar 29, 2011 at 8:59 PM, Eric M. Ludlam <eric@siege-engine.com> wrote:
On 03/29/2011 01:02 PM, York Zhao wrote:
Hi Eric,

Thanks for your reply. I think you missed my point.

Firstly, I believe something should be changed because currently neither
'semantic-symref' nor 'semantic-symref-symbol' work for C++ member
variable. As I had already pointed out, both functions eventually call
the 'cedet-gnu-global-search' with exactly same parameters and finally
'cedet-gnu-global-search' executes 'global' using '-xar'. The problem is
that 'global -r' would find nothing for a C++ member variable. As far as
I can see, in order for 'global' to find references for a member
variable, '-s' needs to be used. Since I'm very new to GNU Global and my
knowledge on 'Global' is very limited, I could be wrong on the '-s' thing.

I agree.  I was hoping someone else would contribute to the conversation to validate your assumption before making a change, but Darren suggested that -r and -s don't work together.


Secondly, even if both these two commands works, they eventually both
call the same function 'cedet-gnu-global-search' with exactly the same
parameters. In both cases, the parameters being passed are:
 texttype='symbol, type='line, scope='project. This makes these two
commands logically identical which I believe is not ideal.

There are two functions so that the default value in the input arg can be different.  They both are asking the same basic question "where is some symbol being used", but semantic-symref asks "where is the tag I am in used", and the other asks "where is the symbol under point used", which are different.  That way you can bind two different keys, and not type in what you want to look for, saving typing.


As a workaround, I added a conditional case '((eq texttype 'symbol)
"rs") which made both commands work for me. However, this is just a
workaround for myself and I don't think it's a good solution, but since
I'm very new to lisp (this was the first time for me to debug in lisp)
and I'm too busy on my project at work, I'm not able to come up with any
better fix at this time.

This implies that r and s arguments are not mutually exclusive, which is good to know.  Your patch also seems reasonable, so I don't see why it cannot be the default.


Lastly, I'm not sure if I'm missing anything and I hope I'm missing
something. I'm not satisfied with the result from GNU Global. Here is my
case:

class A {
  int Var1
}

class B {
  int Var1
}

The problem is when I want the references of A::Var1, I got not only the
references of A::Var1 but also all the references of B::Var1. This is
not good at all even though it's still better than returning nothing.
Microsoft Visual C++ is much better on this which differentiates A::Var1
and B::Var1. Is there anything in GNU Global that I'm not aware of to
achieve this? Or, is there anything semantic could do to differentiate
same variable name defined in different classes?

This is a classic problem with simple tagging utilities.  Simple taggers are pretty good to find lots of references, but you need a full up analysis tool to throw out locations that match by text, by not by context.

Right now semantic symref could do this, but that last step wasn't implemented.  In semantic-symref-result-get-tags there is an opportunity to filter out the bad matches, but the input (detailed info about the tag being searched for) and and filter need to be written.

The implementation, of analyzing every hit, would also be very slow. Another option is to modify semantic-symref-list mode to add a "smart filter" option to post process the list.  That way you can filter only if it matters.

Eric