- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This directory contains Vim scripts for syntax highlighting.
These scripts are not for a language, but are used by Vim itself:
syntax.vim Used for the ":syntax on" command. Uses synload.vim.
manual.vim Used for the ":syntax manual" command. Uses synload.vim.
synload.vim Contains autocommands to load a language file when a certain
file name (extension) is used. And sets up the Syntax menu
for the GUI.
nosyntax.vim Used for the ":syntax off" command. Undo the loading of
synload.vim.
The "shared" directory contains generated files and what is used by more than
one syntax.
A few special files:
2html.vim Converts any highlighted file to HTML (GUI only).
colortest.vim Check for color names and actual color on screen.
hitest.vim View the current highlight settings.
whitespace.vim View Tabs and Spaces.
If you want to write a syntax file, read the docs at ":help usr_44.txt".
If you make a new syntax file which would be useful for others, please send it
to the vim-dev mailing list <vim-dev@vim.org>. Include instructions for
detecting the file type for this language, by file name extension or by
checking a few lines in the file. And please write the file in a portable way,
see ":help 44.12".
If you have remarks about an existing file, send them to the maintainer of
that file. Only when you get no response send a message to the vim-dev
mailing list: <vim-dev@vim.org>.
If you are the maintainer of a syntax file and make improvements, send the new
version to the vim-dev mailing list: <vim-dev@vim.org>
For further info see ":help syntax" in Vim.
a4c085a3e6