Fix command name termination, match bang, and allow a line-continued
argument.
closes: #15358
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
closes: #15944
Signed-off-by: John M Devin <john.m.devin@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
And do not link either to any group.
Resolveszzzyxwvut/java-vim#2.
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Enable folding of class, enum and interface declarations.
- Highlight constructor names with the Function highlight group, like
other special methods.
- Mark function definitions using special method names as errors.
- Highlight :type arguments.
fixes: #14393#issuecomment-2042796198.
closes: #13810
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: tests: cannot run single syntax tests
Solution: Support running a subset of syntax tests
(Aliaksei Budavei)
Two methods of assembling a subset of test filenames for
selection are provided:
* Filename and filetype Make targets will be generated, and
multiple such targets can be passed before the mandated
trailing "test" target, e.g. "make html markdown test".
* Filenames and their parts can be specified as a regular
expression that is assigned to a "VIM_SYNTAX_TEST_FILTER"
environment variable, and used with the test Make target,
e.g. "VIM_SYNTAX_TEST_FILTER=html\\\|markdown make test".
(This variable will be ignored and the whole suite will be
run when Make is GNU Make and a parent Makefile is used.)
Methods can be used alone or together, with the Make targets
having the higher precedence. Neither method will influence
the order of test execution.
closes: #15670
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
With "g:markdown_fenced_languages" defined and "java" added
to its list, a circular dependency between the Markdown and
Java syntax files will be made. To break it, no Markdown
documentation comments will be recognised in fenced blocks
in Markdown files; in order to view Java source files,
"java" must be removed from "g:markdown_fenced_languages",
and this task can be automated as follows.
1) Add to "~/.after/ftplugin/java.vim":
------------------------------------------------------------
if exists("g:markdown_fenced_languages") &&
\ !(exists("g:java_ignore_javadoc") ||
\ exists("g:java_ignore_markdown"))
let s:idx = index(g:markdown_fenced_languages, 'java')
if s:idx > -1
call remove(g:markdown_fenced_languages, s:idx)
endif
unlet s:idx
endif
------------------------------------------------------------
2) Optionally add to "~/.after/ftplugin/markdown.vim":
------------------------------------------------------------
if exists("g:markdown_fenced_languages") &&
\ index(g:markdown_fenced_languages, 'java') < 0
call add(g:markdown_fenced_languages, 'java')
endif
------------------------------------------------------------
(Make sure that the above snippets appear in the files under
the "ftplugin" NOT "syntax" directory.)
Finally, unless the new version of the syntax file is made
available from "$VIMRUNTIME" (and from "~/.vim/syntax" if
necessary), OTHER discoverable file versions will be used
whose behaviour may interfere with this fix.
related: #15740closes: #15796
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Complement "g:java_ignore_javadoc" with "g:java_ignore_html"
and "g:java_ignore_markdown" to allow selectively disabling
the recognition of HTML and CommonMark respectively.
(Note that this is not a preview feature.)
======================== LIMITATION ========================
According to the syntactical details of JEP 467:
> Any leading whitespace and the three initial / characters
> are removed from each line.
>
> The lines are shifted left, by removing leading whitespace
> characters, until the non-blank line with the least
> leading whitespace has no remaining leading whitespace.
>
> Additional leading whitespace and any trailing whitespace
> in each line is preserved, because it may be significant.
the following example:
------------------------------------------------------------
/// A summary sentence.
/// A list:
/// - Item A.
/// - Item B.
///
/// Some code span, starting here `
/// 1 + 2 ` and ending at the previous \`.
------------------------------------------------------------
should be interpreted as if it were written thus:
------------------------------------------------------------
///A summary sentence.
/// A list:
/// - Item A.
/// - Item B.
///
/// Some code span, starting here `
/// 1 + 2 ` and ending at the previous \`.
------------------------------------------------------------
Since automatic line rewriting will not be pursued, parts of
such comments having significant whitespace may be ‘wrongly’
highlighted. For convenience, a &fex function is defined to
‘correct’ it: g:javaformat#RemoveCommonMarkdownWhitespace()
(:help ft-java-plugin).
References:
https://openjdk.org/jeps/467https://spec.commonmark.org/0.31.2closes: #15740
Co-authored-by: Tim Pope <code@tpope.net>
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Define "g:java_syntax_previews" and include number 476 in
its list to enable this recognition:
------------------------------------------------------------
let g:java_syntax_previews = [476]
------------------------------------------------------------
Reference:
https://openjdk.org/jeps/476closes: #15709
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Allow function command modifiers.
- Match function bodies starting with empty lines.
Command modifiers reported by @Konfekt.
fixes#15671closes: #15674
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Define "g:java_syntax_previews" and include number 455 in
its list to enable this recognition:
------------------------------------------------------------
let g:java_syntax_previews = [455]
------------------------------------------------------------
Reference:
https://openjdk.org/jeps/455closes: #15698
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
Match Vim9 boolean and null literals in expression arguments of :if,
:elseif, :while and :return.
closes: #15684
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match -addr and -keepscript attributes and generate -addr values.
- Match attribute errors where = is specified.
- Highlight attributes with Special like other Ex command options.
- Don't highlight user-specified completion function args.
- Match :delcommand -buffer attribute.
closes: #15586
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match '(,'),'[,'],'{, and '} marks in Ex command ranges.
Thanks to Maxim Kim.
Fixes#15332.
Closes#15337.
Signed-off-by: Maxim Kim <habamax@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Introduce a new API variable "g:java_syntax_previews" whose
value must be a list of syntax preview feature numbers.
Enumerate the currently supported numbers in a table at the
end of the documentation entry for "ft-java-syntax".
Also, disable the recognition of String Templates. Despite
the withdrawal of this preview feature in its proposed form
from the upcoming JDK 23 release and the fact that the JDK
22 release is coming to EOL this September, an earlier
iteration of this preview feature was included in JDK 21
(LTS) whose EOL is projected to fall due in late 2028 and,
therefore, retain the current implementation.
Define "g:java_syntax_previews" and include number 430 in
its list to enable the recognition of String Templates:
------------------------------------------------------------
let g:java_syntax_previews = [430]
------------------------------------------------------------
References:
https://openjdk.org/jeps/430 (Preview)
https://openjdk.org/jeps/459 (Second Preview)
https://openjdk.org/jeps/465 (Third Preview)
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.htmlcloses: #15579
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match :loadkeymap after Ex colons and bars.
Don't generate :loadkeymap as it is matched with a custom syntax group.
closes: #15554
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The end marker is not required to match the indent of :let when "trim"
is specified, it may also appear without leading whitespace as normal.
closes: #15564
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Obtain and pass through translated messages with this
function.
- If "g:java_foldtext_show_first_or_second_line" is defined,
assign this function to &foldtext.
closes: #15549
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The end marker must appear on line of its own without any trailing
whitespace.
Whitespace is incorrectly allowed before all end markers. Limiting this
only to heredocs where "trim" was specified, and with the correct
indent, is currently an intractable problem given that contained syntax
groups (in this case :let) cannot be limited to start patterns.
Highlight interpolated expressions when "eval" is specified.
cloess: #15511
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Progress OpenEdge 11.6 added a new C-like single-line comment syntax; such
comments begin with `//` and proceed to the end of the line.
Add a new syntax group `ProgressLineComment` to implement highlighting for this
syntax. Rename the existing group from `ProgressComment` to
`ProgressBlockComment`, and introduce a cluster named `ProgressComment` to
encapsulate both.
closes: #15339
Signed-off-by: Daniel Smith <daniel@rdnlsmith.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
We intend to update the Progress syntax file to support the single-line comment
syntax that was introduced in Progress OpenEdge 11.6. As there are no existing
tests for this file, we should first add one that demonstrates the comment
syntax that is already supported.
related: #15339
Signed-off-by: Daniel Smith <daniel@rdnlsmith.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match bang, "all" and "termcap" options, and trailing command
separator "|".
- Highlight set assignment operators.
- Match multiline :set and multiline option values.
- Mention the newer "0o" octal prefix at :help :set=.
closes: #15329
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This token will be highlighted, similar to the arrow of
lambda expressions, whenever "g:java_highlight_functions" is
defined.
Also:
- Improve the recognition of _switch-case_ labels
(D-Cysteine).
- Remove insignificant empty statements in syntax test
files.
closes: #15322
References:
https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.13https://github.com/fleiner/vim/pull/1
Co-authored-by: D-Cysteine <54219287+D-Cysteine@users.noreply.github.com>
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match :map ( RHS properly.
Only match ! after :map, :noremap, :unmap and :mapclear.
closes: #15297
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Remove extraneous trailing whitespace from legacy script :loadkeymap
test file.
Remove :match *_99.dump test file. These are no longer generated.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match types in Vim9 variable declarations.
Match Vim9 boolean and null literals. These are not matched in all
contexts yet.
related: #15277
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match group and pattern arguments to :match commands.
closes: #15096
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Write a batch of test files with made-up syntax to serve for
additional linewise checks to be manually performed whenever
the algorithm for screen dump file generation is modified.
Define a shell variable VIM_SYNTAX_SELF_TESTING to run these
tests:
cd runtime/syntax/
VIM_SYNTAX_SELF_TESTING=1 make clean test
related: #15150
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
With the variables defined, distinctly highlight parts of
a method declaration header: its name and parameter list
parens, from its type parameters, return type, and formal
parameters; and distinctly highlight parts of a lambda
expression: its parameter list parens and the arrow, from
its formal parameters and identifiers.
closes: #15083
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match Vim9-script comments after :def and :enddef and legacy-script
comments after :func and :endfunc, in any definition context.
Highlight incorrect comment types after these commands as errors.
fixes: #15062closes: #15072
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
In the presence of parameterised types whose names begin
with a capital letter and end with a less-than sign "<" that
introduces a type argument or a list of comma-separated type
arguments, followed by a greater-than sign ">", a variable
"g:java_highlight_generics" can be defined to have some
components of such types uniformly coloured (by picking
highlight groups for javaGenericsC{1,2}, javaWildcardBound).
For example,
------------------------------------------------------------
java.io.InputStream stream = java.io.InputStream.nullInputStream();
java.util.function.Function<String,
java.util.function.BiFunction<String, String, String>> updater =
property -> (oldValue, newValue) -> oldValue;
java.util.logging.LogManager.getLogManager()
.updateConfiguration(stream, updater);
------------------------------------------------------------
Note that the diamond form and explicit type arguments do
not qualify for this kind of recognition.
For example,
------------------------------------------------------------
new java.util.HashSet<>().<String>toArray(new String[0]);
------------------------------------------------------------
References:
https://docs.oracle.com/javase/specs/jls/se21/html/jls-4.html#jls-4.5https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.9https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.12.2.1closes: #15050
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Instances of anonymous classes can be passed as method
arguments and should be subject to line folding as well.
closes: #15048
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>
Match shebang lines in Vim9 and legacy script.
Mark these as an error if they appear anywhere other than the first line
of a legacy-script file. In Vim9 script these match as normal line
comments rather than an error.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Rendered element content results in test failures on macOS and FreeBSD.
The included content for these elements was incidental to the primary
intent of the test to check element tag highlighting so set
g:html_no_rendering to disable content rendering.
FreeBSD fails for even an empty <strike> element.
See #13591 and #14215.
closes: #13595
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match :sleep arg properly including a lone "m" with a leading count.
closes: #15003
Signed-off-by: Doug Kearns <dougkearns@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>
Allow highlighting of strings within comments to be disabled by setting
g:vimsyn_comment_strings to false.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match multiline (continued) line comments.
Continued tail comments are not supported yet.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Allow whitespace between the :substitute command and its pattern
argument. Although unusual, it is supported and there are examples in
the wild.
Match Vi compatible :substitute commands like :s\/{string}/. See :help
E1270.
fixes: #14920closes: #14923
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
* runtime(java): Stop handpicking syntax groups for @javaTop
Also:
- Remove the obsolete comment for g:java_allow_cpp_keywords.
- Remove the commented out groups java\%[Debug\]StringError.
- Infer and set the preferred formatting Vim options from
the modeline.
Since vim-6-0u, non-contained syntax groups can be referred
to by using the "contains=TOP..." argument.
* Set &encoding and &termencoding to "utf-8" for test files
* Limit non-ASCII charset to [§ƒɐɘʬʭΑ-Τα-μ] for test files
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>
