Re: RFR cc-langs.el: change syntax for @ in Java

[Filipp Gunbin <fgunbin@fastmail.fm>]

Hi Alan,

On 12/04/2021 13:36 +0000, Alan Mackenzie wrote:

> I've had a more thorough look at it.  In cc-langs.el, there are several
> places where @ is treated as a symbol character, namely:

I've checked those places before submitting the patch, and I think they
should stay without change.

> L375: c-make-mode-syntax-table (which you have proposed modifying)
> L419: c-identifier-syntax-modifications
> L636: c-symbol-start

I see no problem in leaving them as-is, because they will just continue
to match @ with the following chars as a whole.  It's just when you need
more fine-grained distinction, then you could check if it's prefix or
symbol.

Prefix syntax is defined so that prefix chars are part of the following
expression, that's exactly the case of Java annotations.

> L1969: c-paragraph-start (I think this one only applies in comments)

Yes, this is for javadoc tags, which start with @, and appear only in
comments, like:

/**
 * @param my-param ..
 */

> L2198: c-class-decl-kwds (The "@interface" keyword)

@interface is a keyword which declares the annotation interface itself.

I would really hope that syntax tables do not affect parsing/matching of
keywords.  If they don't, then this place doesn't need to be changed,
either.

> We need to consider whether to amend some or all of these places, so
> that @ ceases to be a (starting) character of an identifier.

I don't think it should cease to be.

> I'm also a bit worried that in
>
>     @NonNull
>     @TestClass
>     @FooBar
>     public class Annotations {
>
> , the last line gets parsed as ((annotation-top-cont 21)), where it
> really ought to be a topmost-intro.  But this problem is present without
> your patch, anyway.
>
> In summary, I think the motivation for the change (highlighting symbols
> correctly) is valid, but the change is going to be more involved than
> the patch you've supplied.

It's not about highlighting, but rather about "extracting" @, to be able
to request the non-@ part separately.

But maybe I'm missing something.

Thanks.
Filipp