> The problem is that code changes out from under GNU Global, so as you
> edit code, the line numbers change, so we need to snoop around to find
> the tag you're looking for.

Well, if I get the feature working reasonably, I'll probably use it when editing code.

Why go through the trouble of snooping around the code when GNU Global's incremental updating is fast?  Can't CEDET run 'global -u' and then assume line number accuracy?

> Of course, why are there 1238 hits from global?  I'm guessing from your
> explanation above that the parent of myUtilFunc is some generic word
> like "std" or something.  In order for the impl-proto jump to work, it
> has to find the correct parent of the symbol you want to toggle on on
> the off chance that your tag is in a bunch of different names
> spaces/classes.

It's not in the std namespace.  The structure is like:
   namespace A { namespace B { namespace C { myUtilFunc declaration } } }

CEDET visited .cc files with no members in the B or C namespace.  Most of the project is in the A namespace, so I'm not sure if it would open files without a namespace A.

> The assumption, of course, is that you might have oodles of hits on the
> tag name, and less on the parent name, but your case is the opposite.

Yes, that's true.  I would think this would be true for most projects, since functions are named very particularly and namespaces typically have many members.  Thus, shouldn't the default behavior be to get the matches for the tag first and then use parents to narrow that set of results?

> A quick hack might be to visit the function
> semantic--analyze-refs-full-lookup and force the if statement to only do
> the simple lookup.  If it "works" and is fast, then we'll know we're on
> the right track, and perhaps that code should do the simple search
> first, see if it is successful, then try the slower version.

Well, it was reasonably fast at about one second, but is now incorrect.  It took me to the other definition of a myUtilFunc rather than the correct one.