Commit Graph

18 Commits

Author SHA1 Message Date
Christian Clason
b7e5769132 vim-patch:c4d0c8c81245
runtime(java): Improve the recognition of the "indent" method declarations (vim/vim#14659)

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.

c4d0c8c812

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-30 00:10:02 +02:00
Christian Clason
30374db955 vim-patch:a4c085a3e607
runtime(java): Improve the recognition of the "style" method declarations

- 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: vim/vim#14620

a4c085a3e6

Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-25 08:23:39 +02:00
zeertzjq
537ba34953
vim-patch:4052474a1bd2 (#28358)
runtime(java): Recognise non-ASCII identifiers (vim/vim#14543)

* runtime(java): Recognise non-ASCII identifiers

Also:

- Remove the already commented out and less general in its
  definition javaFuncDef alternative.

- Stop recognising some bespoke {p,trace} debugging API.

Non-ASCII identifiers have been supported from the outset
of the Java language.

> An _identifier_ is an unlimited-length sequence of _Java
> letters_ and _Java digits_, the first of which must be a
> Java letter.  An identifier cannot have the same spelling
> (Unicode character sequence) as a keyword . . . Boolean
> literal . . . or the null literal . . .
> . . . . . . . .
> Letters and digits may be drawn from the entire Unicode
> character set . . .
> . . . . . . . .
> A Java letter is a character for which the method
> Character.isJavaLetter . . . returns true.  A Java
> letter-or-digit is a character for which the method
> Character.isJavaLetterOrDigit . . . returns true.
> . . . . . . . .
> The Java letters include . . . for historical reasons, the
> ASCII underscore (_) . . . and dollar sign ($) . . .

(Separate syntax tests will be written when particular parts
now touched will have been further improved.)

Reference:
https://javaalmanac.io/jdk/1.0/langspec.pdf [§3.8]

* Take on the maintenance of Java filetype and syntax files

4052474a1b

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-16 09:32:55 +08:00
Christian Clason
4add77ddbf vim-patch:5ccdcc482e29
runtime(java): Improve the matching of contextual keywords

- Recognise a _record_ contextual keyword.
- Recognise _non-sealed_, _sealed_, and _permits_ contextual
  keywords.
- Admit _$_ to keyword characters.
- Group _abstract_, _final_, _default_, _(non-)sealed_
  (apart from _(non-)sealed_, the incompossibility of these
  modifiers calls for attention).
- Remove another _synchronized_ keyword redefinition.

I have also replaced a function with an expression.  Before
patch 8.1.0515, it should have been declared :function! to
work with repeatable script sourcing; there is less to worry
about with an expression.

References:
https://openjdk.org/jeps/395 (Records)
https://openjdk.org/jeps/409 (Sealed Classes)
https://docs.oracle.com/javase/specs/jls/se21/html/jls-3.html#jls-3.8

closes: vim/vim#14403

5ccdcc482e

Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-05 09:07:07 +02:00
Christian Clason
3587377cda vim-patch:63d68c2c218e
runtime(java): Update java[CR]_JavaLang type lists (vim/vim#14297)

- Add to the list of java.lang runtime exceptions two new
  types: MatchException (Pattern Matching for _switch_) and
  WrongThreadException (Virtual Threads).
- "Demote" Compiler (removed in JDK 21) from the list of
  java.lang class types to a new list javaLangDeprecated.

References:
https://bugs.openjdk.org/browse/JDK-8205129
https://bugs.openjdk.org/browse/JDK-8282274
https://bugs.openjdk.org/browse/JDK-8284161

63d68c2c21

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-26 21:37:50 +01:00
Christian Clason
31c4cb2347 vim-patch:8e59a7ba8877
runtime(java): Recognise the inline kind of the {@return} tag (vim/vim#14284)

Also:

- Refine comment matching (javaComment{Error\ and,Start}).
- Continue rewriting regexps (prefer atom grouping with
  non-capturing parens; factor out common prefixes in
  alternations).
- Allow for relative paths with the _file_ attribute of
  {@snippet}.
- Anticipate HTML in the @see tags.
- Match the nullary method parens in javaDocSeeTagParam.
- Improve the boundary patterns for summary sentences of
  documentation.

> This sentence ends at ... or at the first tag (as defined
> below).

There are Java documentation tags (@) and there are HTML
tags (<?>) (with Markdown looming large; see JEP 467).  With
block tags, e.g. @param, @return, @see, we begin another
documentation "sentence" whether or not the author has
terminated the summary sentence with a period; with
.<!-- -->, we may follow abbreviations, enumerations,
initials, (but instead consider @literal or &nbsp;) _within_
the summary sentence.  On the other hand, inline tags, e.g.
@code, @link, @literal, should not terminate the summary
sentence.

References:
https://bugs.openjdk.org/browse/JDK-8075778
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#firstsentence
https://docs.oracle.com/en/java/javase/21/docs/specs/javadoc/doc-comment-spec.html

8e59a7ba88

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-25 21:39:46 +01:00
Christian Clason
31a15fb2a1 vim-patch:3e72bf10a0a2
runtime(java): Recognise the {@snippet} documentation tag (vim/vim#14271)

Remember that ‘code fragments are typically Java source
code, but they may also be fragments of properties files,
source code in other languages, or plain text.’  Therefore,
with these changes, markup tags are highlighted in the Java
source files (as external snippets) and in the {@snippet}
tags.

Also:

- Improve matching of the multi-line {@code} documentation
  tag with any contained balanced braces.
- Recognise the {@literal} documentation tag.
- Highlight stray blanks in comments.

Related to an enhancement proposal for PCRE-like callouts
discussed at https://github.com/vim/vim/issues/11217.

References:
https://openjdk.org/jeps/413
https://docs.oracle.com/en/java/javase/21/docs/specs/javadoc/doc-comment-spec.html

3e72bf10a0

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-25 14:18:52 +01:00
Christian Clason
3c66e285cc vim-patch:a2c65809dafe
runtime(java): Recognise string templates (vim/vim#14150)

As this is encouraged in the referenced JEPs, "to visually
distinguish a string template from a string literal, and
a text block template from a text block", the default
colours for java\%[Debug]StrTempl are made distinct from
java\%[Debug]String.

According to §3.2 Lexical Translations (JLS, c. 1996 or any
more recent version), line terminators, white space, and
comments are discarded before tokens are accepted. Since
a template expression comprises a template processor, a dot,
and a template, it may be visually appealing to break up
its head across a few lines whenever its tail already spans
multiple lines.  Curiously, no allowance for it is made in
the distributed tests for OpenJDK 21; the proposed regexp
patterns take in consideration a line terminator and white
space after a dot.

References:
https://openjdk.org/jeps/430 (Preview)
https://openjdk.org/jeps/459 (Second Preview)
https://openjdk.org/jeps/465

a2c65809da

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-10 10:36:26 +08:00
Christian Clason
3971797be1 vim-patch:b3030b653bbd
runtime(java): Recognise text blocks (vim/vim#14128)

Also, accept as valid the space escape sequence `\s`.

Also, consistently use the claimed `javaDebug` prefix for
syntax group definitions kept under `g:java_highlight_debug`.

Since `javaStringError` is commented out for its generality,
let's comment out `javaDebugStringError`, its copy, as well.

References:
https://openjdk.org/jeps/378
https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.10.7

Closes vim/vim#10910.

b3030b653b

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-03 17:41:04 +01:00
Christian Clason
72e0ef2f46 vim-patch:100a665634a0
runtime(java): Improve the recognition of literals (vim/vim#14120)

* Emend the Unicode and octal escape sequence patterns;
* Accept the (repeated) underscore separators in all
  numerical literals;
* Recognise hexadecimal floating-point literals.

(The space escape sequence '\s' will be introduced along
with text blocks in another PR.)

References:
https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.3
https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.10.1
https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.10.2
https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.10.7

100a665634

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-02 10:06:26 +01:00
Christian Clason
86c3f284fc vim-patch:9ecf02cd5f5f
runtime(java): Recognise _when_ clauses in _switch_ blocks

Also:

- distinguish _yield_ when used as a contextual keyword from
  when used qualified as a method or a method reference (as
  can be seen in testdir/input/java_switch.java, variables
  and method declarations named _yield_ will be recognised
  as the namesake keyword--consider picking other names for
  variables, and defining g:java_highlight_functions to have
  method names painted; since _yield_ statements can have
  trailing parens, they must be recognised as statements,
  for only qualified _yield_ method calls are supported);

- recognise grouped _default_ _case_ labels;

- describe primitive types for _case_ labels (JLS, §14.11,
  §3.10.1);

- recognise some non-ASCII identifiers (see javaLambdaDef,
  javaUserLabel) (further improvement for better recognition
  of identifiers will be arranged in a separate PR).

Because the arrow '->' is used in two kinds of expressions,
lambda (abstractions) and _switch_, necessary changes were
made for the recognition of either (and further improvement
touching lambda expressions will be separately arranged).

Because 'default' is used for instance method declarations
in interfaces and in _switch_ labels, necessary changes were
made for the recognition of either (and further improvement
touching method declarations will be separately arranged).

Finally, it deemed appropriate to put 'yield' in the syntax
group of javaOperator rather than javaStatement, for its
member 'var' is also another contextual keyword (e.g., this
is valid syntax: "var var = var(test.var);").

References:
https://openjdk.org/jeps/361 (Switch Expressions)
https://openjdk.org/jeps/440 (Record Patterns)
https://openjdk.org/jeps/441 (Pattern Matching for switch)

Also, add a Java specific filetype plugin for the syntax
test, so that no soft-wrapping of long indented lines occur.

Otherwise the syntax scripts would miss a few lines during
scrolling and verification of the screen dumps.

closes: vim/vim#14105

9ecf02cd5f

Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 09:53:09 +01:00
Christian Clason
0760d98680 vim-patch:20d61e1b94e5
runtime(java): add syntax support for Java switch expressions (#9124)

20d61e1b94

Co-authored-by: Nick Hanley <nicholasjhanley@gmail.com>
2024-02-22 16:27:56 +01:00
Christian Clason
6eaf10502c
vim-patch:partial:63f32603789d (#18916)
Update runtime files
63f3260378

skip translations
skip user manual rewrite
2022-06-10 08:40:32 +02:00
Justin M. Keyes
07fdbba9d0 vim-patch:91f84f6e11cd
Update runtime files.
91f84f6e11
2018-10-29 09:55:07 +01:00
Justin M. Keyes
86b596dc7a vim-patch:f37506f60f87
Updated runtime files.  Remove HiLink commands.

f37506f60f
2017-04-28 21:25:15 +02:00
Justin M. Keyes
a53409b564 vim-patch:89bcfda6834a
Updated runtime files.  Remove version checks for Vim older than 6.0.

89bcfda683
2017-04-28 21:13:55 +02:00
Justin Gassner
fec466c72e vim-patch:f3c2afb
Update a few runtime files.

f3c2afb77f
2016-01-15 16:09:46 +01:00
Justin M. Keyes
a98a6996c2 re-integrate runtime/ vim-patch:0 #938
Vim runtime files based on 7.4.384 / hg changeset 7090d7f160f7

Excluding:
  Amiga icons (*.info, icons/)
  doc/hangulin.txt
  tutor/
  spell/
  lang/ (only used for menu translations)
  macros/maze/, macros/hanoi/, macros/life/, macros/urm/
      These were used to test vi compatibility.
  termcap
      "Demonstration of a termcap file (for the Amiga and Archimedes)"

Helped-by: Rich Wareham <rjw57@cam.ac.uk>
Helped-by: John <john.schmidt.h@gmail.com>
Helped-by: Yann <yann@yann-salaun.com>
Helped-by: Christophe Badoit <c.badoit@lesiteimmo.com>
Helped-by: drasill <github@tof2k.com>
Helped-by: Tae Sandoval Murgan <taecilla@gmail.com>
Helped-by: Lowe Thiderman <lowe.thiderman@gmail.com>
2014-07-29 02:12:31 +00:00