I found out how to search the lists (see the "Mailing lists" drop-down in the main project navigation bar)and found that discussion you mentioned. Quite an old one, from 2010. But things did not change a lot since then, thus we can start from that point.
You wrote that there is no such mechanic available. I can see two ways of solving the issue:
1. overload the main completing function and implement Java-specific filtering.
2. add a generic mechanism to handle such cases (filtering completion list using language-specific rules) with a reasonable default implementation.
I prefer the second variant, as most of Cedet languages would benefit from it (C++, Java, Python). Eric, what do you think?
I guess I could implement that and post the patch here for discussion, along with other bug-fixes and minor improvements I have in my local branch. Legal papers are on their way to FSF.
BTW, Eric, is there a special policy for Cedet contributors? I would like work on Java support in Cedet on regular basis.
On 11/14/2012 02:49 PM, Vladimir Kazanov wrote:This came up once before, and the conversation is somewhere in the cedet-devel archive. I'm not sure how to search the sourceforge mailing list archive anymore though. Too bad, as I had some data on the problems related to getting this working. Maybe someone out there knows how to do the search?
While fixing bugs I noticed that Cedet (for Java) does not separate
static/instance contexts. In static functions and blocks only tags with
the "static" typemodifier should be accessible, and both static and
usual methods/vars/classes in an instance context.
I thinking about implementing this particular feature, and this should
not be too hard, as all the info required is already available in tags
received upon completion. I've spent an hour or two trying to find a
canonical way to implement this, but failed. Which is confusing! In
three languages Cedet claims to support there is such a concept.
Maybe I missed something? Or overloading
semantic-analyze-possible-completions-default function with a
java-specific one is the only way..? Or even extending a default
function would be reasonable?