Re: [CEDET-devel] Why 'semantic-symref' logically identical to 'semantic-symref-symbol'
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2011-03-30 00:59:51
|
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 |