CEDET

Hello,

I've run into a problem in semantic, using Java, where semantic will not
recognize class variables named "version". In other words, calling
semantic-describe-token upon a class variable named "version"
erroneously returns the class description, not the token at point.
Changing the variable name fixes the problem.

Upon investigation, I discovered that the variable
semantic-java-keyword-table defines a number of terms as keywords that
are not keywords: author, version, param, exception, see, since, serial,
serialData, serialField, deprecated. The second part of
semantic-java-keyword-table correctly identifies these keywords as
belonging to javadoc, but apparently the bovinator makes no such
distinction.

Is there any way to fix this problem without deleting the entries from
the keyword table? I'm always uncomfortable modifying distributed code,
especially in such a great package as semantic :)

Stuart

>>> Stuart Popejoy <stuart@...> seems to think that:
>Hello,
>
>I've run into a problem in semantic, using Java, where semantic will not
>recognize class variables named "version". In other words, calling
>semantic-describe-token upon a class variable named "version"
>erroneously returns the class description, not the token at point.
>Changing the variable name fixes the problem.
>
>Upon investigation, I discovered that the variable
>semantic-java-keyword-table defines a number of terms as keywords that
>are not keywords: author, version, param, exception, see, since, serial,
>serialData, serialField, deprecated. The second part of
>semantic-java-keyword-table correctly identifies these keywords as
>belonging to javadoc, but apparently the bovinator makes no such
>distinction.
>
>Is there any way to fix this problem without deleting the entries from
>the keyword table? I'm always uncomfortable modifying distributed code,
>especially in such a great package as semantic :)
  [ ... ]

Hi,

  The keyword information was set up to display information about the
  @version tags in comments to give hints on usage while you edit.
  This seems to be an unfortunate side-effect.

  I don't think there is a good way around the problem without
  re-writing parts of the java support file.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

>>> Ole Laursen <olau@...> seems to think that:
>Hi!
>
>While exploring the wonders of Semantic 1.4 (very cool, though the
>completion part seems a little flaky :-), in C++ mode I encountered a
>few problems. The following results in unmatched syntax:
>
>  class Test
>  {
>    struct Inner;
>
>    int foo;
>  };
>
>  struct Test::Inner      // these
>  {                       // lines
>    int bar;              // are
>  };                      // underlined
>
>
>So it seems definition of nested classes outside the outer class
>doesn't work?

Hi,

  The struct does work if you have just one colon.  I don't use C++ so
I don't know what the difference is.

>Also, namespace qualification of member variables doesn't seem to be
>recognized. In the following I get a red line under the 'std::' part:
>
>  class Test
>  {
>    std::list<int> foo_list;
>  };

Yup, another permutation.  This will be fixed in semantic 1.4.1.

Thanks
Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

> >  class Test
> >  {
> >    struct Inner;
> >
> >    int foo;
> >  };
> >
> >  struct Test::Inner      // these
> >  {                       // lines
> >    int bar;              // are
> >  };                      // underlined
> >
> >
> >So it seems definition of nested classes outside the outer class
> >doesn't work?
> 
> Hi,
> 
>   The struct does work if you have just one colon.  I don't use C++ so
> I don't know what the difference is.

One colon means "inherits from", so that Test inherits with restricted
access from Inner. A double colon is the scope resolution operator;
the above structure definition is supposed to mean "define the struct
Inner which is a member of Test as ...".

> >Also, namespace qualification of member variables doesn't seem to be
> >recognized. In the following I get a red line under the 'std::' part:
> >
> >  class Test
> >  {
> >    std::list<int> foo_list;
> >  };
> 
> Yup, another permutation.  This will be fixed in semantic 1.4.1.

Great!

-- 
Ole Laursen
http://sunsite.dk/olau/

>>> Ole Laursen <olau@...> seems to think that:
>> >  class Test
>> >  {
>> >    struct Inner;
>> >
>> >    int foo;
>> >  };
>> >
>> >  struct Test::Inner      // these
>> >  {                       // lines
>> >    int bar;              // are
>> >  };                      // underlined
>> >
>> >
>> >So it seems definition of nested classes outside the outer class
>> >doesn't work?
>> 
>> Hi,
>> 
>>   The struct does work if you have just one colon.  I don't use C++ so
>> I don't know what the difference is.
>
>One colon means "inherits from", so that Test inherits with restricted
>access from Inner. A double colon is the scope resolution operator;
>the above structure definition is supposed to mean "define the struct
>Inner which is a member of Test as ...".

Oh dear me.  Ok.  I have some algorithms that attempt to construct a
representation of a class by finding occurrences of methods defined
outside the scope of a class and building a parallel representation.
I hadn't realized the same is true for structures.  I can make it
parse, but I won't be able to recreate the whole until semantic 2.0
where we are rebuilding the internals of our representation.

Thanks.
Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ludlam.net            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:
> >One colon means "inherits from", so that Test inherits with restricted
> >access from Inner. A double colon is the scope resolution operator;
> >the above structure definition is supposed to mean "define the struct
> >Inner which is a member of Test as ...".
> 
> Oh dear me.  Ok.  I have some algorithms that attempt to construct a
> representation of a class by finding occurrences of methods defined
> outside the scope of a class and building a parallel representation.
> I hadn't realized the same is true for structures.  I can make it
> parse, but I won't be able to recreate the whole until semantic 2.0
> where we are rebuilding the internals of our representation.

OK, I'll look forward to 2.0 then. :-)

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/