Stop assigning by default the NonText highlighting group for
javaConceptKind modifiers since its colour is hardly
distinguishable from a background colour for a range of
colour schemes.
fixes#15237
related #15238closes: #15664
Co-authored-by: Dexter Gaon-Shatford <dexter@gaonshatford.ca>
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Also:
- Restore the capability to mark as an error braces nested
in parens with g:javaInParen.
- Try not to fold top-level-type bodies. (Defining multiple
package-private top level types in a single source file is
not recommended as it can impose order among compilation
units; so it is assumed that only one such top level type
is usually defined.)
- Compose ‘method header’ highlighting and block braces
folding.
- Do not highlight block braces whenever ‘method header’
highlighting is requested.
This bundling of ‘method headers’ and block braces for
highlighting can be traced back to Vim v5.0; however, no
comment or documentation entry conveys any justification.
For example, it is hard to discover the connection between
block braces for "while", "if", etc., statements and method
body block braces. The former behaviour can be attained in,
e.g. ~/.vim/after/syntax/java.vim:
------------------------------------------------------------
if exists("g:java_highlight_functions")
syn clear javaBlock javaInParen
syn match javaBlockOther "[{}]"
syn region javaBlock transparent matchgroup=javaBlockStart
\ start="\%(^\|^\S[^:]\+\)\@120<!{" end="}" fold
hi def link javaBlockStart javaFuncDef
hi def link javaBlockOther javaBlockStart
if exists("g:java_mark_braces_in_parens_as_errors")
syn match javaInParen contained "[{}]"
endif
endif
------------------------------------------------------------
Note: Read ‘a method header omitting a _throws_ clause’ for
every ‘method header’ appellation used above.
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Make a formal definition for normal and single-element kinds
of annotations that otherwise require for their containment
to repeat each time all syntax groups that describe element
values.
Reference:
https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.7
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
There is a flaw in the current implementation that has been
exacerbated around v5.2. It lies in the recognition of all
three indentation styles simultaneously: a tab, two space,
and eight space character(s). With it, it is not uncommon
to misidentify various constructs as method declarations
when they belong to two-space indented members and other
blocks of a type and are offset at eight space characters or
a tab from the start of the line.
For example,
------------------------------------------------------------
class Test
{
static String hello() { return "hello"; }
public static void main(String[] args)
{
try {
if (args.length > 0) {
// FIXME: eight spaces.
System.out.println(args[0]);
} else {
// FIXME: a tab.
System.out.println(hello());
}
} catch (Exception e) {
throw new Error(e);
}
}
}
------------------------------------------------------------
------------------------------------------------------------
:let g:java_highlight_functions = 'indent'
:doautocmd Syntax
------------------------------------------------------------
A better approach is to pick an only indentation style out
of all supported styles (so either two spaces _or_ eight
spaces _or_ a tab). Note that tabs and spaces can still be
mixed, only the leading tab or the leading run of spaces
matters for the recognition. And there is no reason to not
complement the set of valid styles with any number of spaces
from 1 to 8, inclusively.
Please proceed with the necessary change as follows:
- rename from "indent" to "indent2" for a 2-space run;
- rename from "indent" to "indent8" for an 8-space run;
- continue to have "indent" for a tab run;
- define an "indent" variable with a suffix number denoting
the preferred amount of indentation for any other run of
spaces [1-8].
As before, this alternative style of recognition of method
declarations still does not prescribe naming conventions and
still cannot recognise method declarations in nested types
that are conventionally indented.
The proposed changes also follow suit of "style" in stopping
the claiming of constructor and enum constant declarations.
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
