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>
Problem: tiny vim fails because of line-continuation, although
the test script should be skipped for non-eval builds of Vim.
Solution: :set cpo&vim
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>
Problem: tests: Analyzing failed screendumps is hard
Solution: Facilitate the viewing of rendered screendumps under src/
add some documentation on how to use the viewdumps.vim
script (Aliaksei Budavei)
With the submitted "viewdumps.vim" script, a few manual
steps in typical workflows (see below) can be automated.
The updated "README.txt" contains additional information.
============================================================
Reviewing LOCAL failed screendump tests can be arranged as
follows:
1) Run tests and generate screendumps:
------------------------------------------------------------
cd /path/to/fork/src/testdir
make
------------------------------------------------------------
2) Examine the screendumps from the "failed" directory:
------------------------------------------------------------
../vim -u NONE -S viewdumps.vim
------------------------------------------------------------
============================================================
Reviewing UPLOADED failed screendump tests can be arranged
as follows (it can be further locally scripted):
1) Fetch an artifact with failed screendumps from
"github.com/vim/vim/actions/runs/A_ID/artifacts/B_ID".
2) Extract the archived files:
------------------------------------------------------------
unzip /tmp/failed-tests.zip -d /tmp
------------------------------------------------------------
3) Set up the "dumps" directory. Create a symlink to
"/path/to/fork/dirs/dumps" in the extracted directories so
that term_dumpdiff() can be used. (The lookup algorithm
resolves "dumps" for every loaded filename. So, with
"/tmp/src/testdir/failed/*.dump" files passed as script
arguments, the algorithm will make the files in
"/tmp/src/testdir/dumps" queried.)
------------------------------------------------------------
cd /path/to/fork
ln -s $(pwd)/src/testdir/dumps /tmp/src/testdir/dumps
------------------------------------------------------------
4) Examine the extracted screendumps:
------------------------------------------------------------
./src/vim -u NONE -S src/testdir/viewdumps.vim \
/tmp/src/testdir/failed/*.dump
------------------------------------------------------------
5) Clean up:
------------------------------------------------------------
unlink /tmp/src/testdir/dumps
rm -rf /tmp/src
------------------------------------------------------------
============================================================
Reviewing SUBMITTED FOR PULL REQUEST screendump tests can be
arranged as follows (it can be further locally scripted):
1) List the fetched changeset and write the changed "dumps"
filenames to "/tmp/filelist":
------------------------------------------------------------
cd /path/to/fork
git switch prs/1234
git diff-index --relative=src/testdir/dumps/ \
--name-only prs/1234~1 > /tmp/filelist
------------------------------------------------------------
2) Reconcile relative filepaths, and copy next-to-be-updated
"dumps" files in the "failed" directory (note the missing
new screendumps, if any):
------------------------------------------------------------
git switch master
cd src/testdir/dumps
test -d ../failed || mkdir ../failed
cp -t ../failed $(cat /tmp/filelist)
------------------------------------------------------------
3) Remember about the introduced INVERTED relation between
"dumps" and "failed", i.e. the files to be committed are in
"dumps" already and their previous versions are in "failed";
therefore, copy the missing new screendumps from "dumps" to
"failed" (otherwise these won't be shown):
------------------------------------------------------------
git switch prs/1234
cp -t ../failed foo_10.dump foo_11.dump foo_12.dump
------------------------------------------------------------
4) Examine the screendumps from the "failed" directory (new
screendumps will be shown with no difference between their
versions):
------------------------------------------------------------
cd ..
../vim -u NONE -S viewdumps.vim
------------------------------------------------------------
closes: #15515
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>
With the submitted "viewdumps.vim" script, a few manual
steps in typical workflows (see below) can be automated.
The updated "README.txt" contains additional information.
============================================================
Reviewing LOCAL failed syntax tests can be arranged as
follows:
1) Run tests and generate screendumps:
------------------------------------------------------------
cd /path/to/fork/runtime/syntax
make clean test
------------------------------------------------------------
2) Examine the screendumps from the "failed" directory:
------------------------------------------------------------
../../src/vim --clean -S testdir/viewdumps.vim
------------------------------------------------------------
============================================================
Reviewing UPLOADED failed syntax tests can be arranged as
follows (it can be further locally scripted):
1) Fetch an artifact with failed screendumps from
"github.com/vim/vim/actions/runs/A_ID/artifacts/B_ID".
2) Extract the archived files:
------------------------------------------------------------
unzip /tmp/failed-tests.zip -d /tmp
------------------------------------------------------------
3) Set up the "dumps" directory. Create a symlink to
"/path/to/fork/dirs/dumps" in the extracted directories so
that term_dumpdiff() can be used. (The lookup algorithm
resolves "dumps" for every loaded filename. So, with
"/tmp/runtime/syntax/testdir/failed/*.dump" files passed
as script arguments, the algorithm will make the files in
"/tmp/runtime/syntax/testdir/dumps" queried.)
------------------------------------------------------------
cd /path/to/fork
ln -s $(pwd)/runtime/syntax/testdir/dumps \
/tmp/runtime/syntax/testdir/dumps
------------------------------------------------------------
4) Examine the extracted screendumps:
------------------------------------------------------------
./src/vim --clean -S runtime/syntax/testdir/viewdumps.vim \
/tmp/runtime/syntax/testdir/failed/*.dump
------------------------------------------------------------
5) Clean up:
------------------------------------------------------------
unlink /tmp/runtime/syntax/testdir/dumps
rm -rf /tmp/runtime
------------------------------------------------------------
============================================================
Reviewing SUBMITTED FOR PULL REQUEST syntax tests can be
arranged as follows (it can be further locally scripted):
1) List the fetched changeset and write the changed "dumps"
filenames to "/tmp/filelist":
------------------------------------------------------------
cd /path/to/fork
git switch prs/1234
git diff-index --relative=runtime/syntax/testdir/dumps/ \
--name-only prs/1234~1 > /tmp/filelist
------------------------------------------------------------
2) Reconcile relative filepaths, and copy next-to-be-updated
"dumps" files in the "failed" directory (note the missing
new screendumps, if any):
------------------------------------------------------------
git switch master
cd runtime/syntax/testdir/dumps
cp -t ../failed $(cat /tmp/filelist)
------------------------------------------------------------
3) Remember about the introduced INVERTED relation between
"dumps" and "failed", i.e. the files to be committed are in
"dumps" already and their previous versions are in "failed";
therefore, copy the missing new screendumps from "dumps" to
"failed" (otherwise these won't be shown):
------------------------------------------------------------
git switch prs/1234
cp -t ../failed foo_10.dump foo_11.dump foo_12.dump
------------------------------------------------------------
4) Examine the screendumps from the "failed" directory (new
screendumps will be shown with no difference between their
versions):
------------------------------------------------------------
cd ..
../../../src/vim --clean -S viewdumps.vim
------------------------------------------------------------
closes: #15476
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Reword a few sentences and reformat a few paragraphs.
- Supply absent capitalisation and punctuation.
- Make listed highlighting groups and code stand out.
- Prefix all Java-related global variables with "g:".
- Add spaces around each variable assignment operator.
- Acknowledge that some Javadoc variables are maintained in
the HTML syntax file.
Also, move the overridable _default_ HTML group links before
the HTML syntax file inclusion in order to implement the
documented diverged settings.
related: #15399
Signed-off-by: Aliaksei Budavei <0x000c70@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>
- Remove the code handling their generation.
- Remove the code written for the shell filetype to clear up
the buffer screen before such a file can be generated.
- Remove all but "yaml.yaml_99.dump" of such generated files
(since there is no published "input/yaml.yaml.yaml", let
its maintainer regenerate screen dump files and remove
redundant ones).
The new algorithm turns a "*_99.dump" file obsolete because
all lines written in such a file will already be present in
lower-numbered "*.dump" files.
Signed-off-by: Aliaksei Budavei <0x000c70@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>
Track the cursor forward progress through a syntax test file
so that any degenerate input can be checked and reported.
closes: #15150
Signed-off-by: Aliaksei Budavei <0x000c70@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>
The current contents of sh_01_99.dump and sh_09_99.dump
begin with ":redraw" in the ruler line whereas both the
comment and the need for the redraw command execution imply
blanks " ".
related: #15150
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The current implementation falls short for syntax test files
on two accounts:
1. With folded lines -- some lines before folded lines are
unnecessarily repeated in generated dump files because
closed folded lines are always treated as opened for the
cursor to move _in_ instead of to move _over_ them.
2. With wrapped lines (longer than 75 columns) -- some lines
are omitted in generated dump files because calculations
for the cursor progress and its movement commands only
refer to file lines and not their layout within a 20x75
buffer (less &cmdheight).
As an alternative, we abandon deterministic (and inaccurate
at times) calculations for the cursor progress and, instead,
advance the cursor by as much as before for a single dump
file, but now rely on marking the last visible line and
additional movement to position lines at desired offsets,
carefully preserving compatibility for the &scrolloff and
&ruler values inherited from defaults.vim. The parent Vim
process will keep track of progress through a syntax test
file made by its child process ("terminal") by reading the
rightmost end of the ruler line from the terminal buffer,
looking for " All " or " Bot " for its cue to finish dump
file generation.
With these changes applied, the lossless line length limit
will be raised from 75 to 1425 (for a 19x75 view) columns.
Also, prefer "lastline" to "truncate" for &display; hiding
the content of any last _long_ line in a view goes against
the purpose of syntax file testing -- all lines should be
recorded.
related: #15150fixes: #14245
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>
