neovim/runtime/syntax/java.vim

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

565 lines
30 KiB
VimL
Raw Normal View History

" Vim syntax file
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 https://github.com/vim/vim/commit/4052474a1bd2fe756bc7dc596d29d0d7581e35ae Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-15 18:32:55 -07:00
" Language: Java
" Maintainer: Aliaksei Budavei <0x000c70 AT gmail DOT com>
" Former Maintainer: Claudio Fleiner <claudio@fleiner.com>
" Repository: https://github.com/zzzyxwvut/java-vim.git
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
" Last Change: 2024 Jun 15
" Please check :help java.vim for comments on some of the options available.
" quit when a syntax file was already loaded
if !exists("main_syntax")
if exists("b:current_syntax")
finish
endif
" we define it here so that included files can test for it
let main_syntax='java'
endif
let s:cpo_save = &cpo
set cpo&vim
"""" STRIVE TO REMAIN COMPATIBLE FOR AT LEAST VIM 7.0.
let s:ff = {}
function! s:ff.LeftConstant(x, y) abort
return a:x
endfunction
function! s:ff.RightConstant(x, y) abort
return a:y
endfunction
if !exists("*s:ReportOnce")
function s:ReportOnce(message) abort
echomsg 'syntax/java.vim: ' . a:message
endfunction
else
function! s:ReportOnce(dummy)
endfunction
endif
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
function! JavaSyntaxFoldTextExpr() abort
return getline(v:foldstart) !~ '/\*\+\s*$'
\ ? foldtext()
\ : printf('+-%s%3d lines: ',
\ v:folddashes,
\ (v:foldend - v:foldstart + 1)) .
\ getline(v:foldstart + 1)
endfunction
" E120 for "fdt=s:JavaSyntaxFoldTextExpr()" before v8.2.3900.
setlocal foldtext=JavaSyntaxFoldTextExpr()
" Admit the ASCII dollar sign to keyword characters (JLS-17, §3.8):
try
exec 'syntax iskeyword ' . &l:iskeyword . ',$'
catch /\<E410:/
call s:ReportOnce(v:exception)
setlocal iskeyword+=$
endtry
" some characters that cannot be in a java program (outside a string)
syn match javaError "[\\@`]"
syn match javaError "<<<\|\.\.\|=>\|||=\|&&=\|\*\/"
" use separate name so that it can be deleted in javacc.vim
syn match javaError2 "#\|=<"
hi def link javaError2 javaError
" Keywords (JLS-17, §3.9):
syn keyword javaExternal native package
syn match javaExternal "\<import\>\%(\s\+static\>\)\="
syn keyword javaError goto const
syn keyword javaConditional if else switch
syn keyword javaRepeat while for do
syn keyword javaBoolean true false
syn keyword javaConstant null
syn keyword javaTypedef this super
syn keyword javaOperator new instanceof
syn match javaOperator "\<var\>\%(\s*(\)\@!"
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
" Since the yield statement, which could take a parenthesised operand,
" and _qualified_ yield methods get along within the switch block
" (JLS-17, §3.8), it seems futile to make a region definition for this
" block; instead look for the _yield_ word alone, and if found,
" backtrack (arbitrarily) 80 bytes, at most, on the matched line and,
" if necessary, on the line before that (h: \@<=), trying to match
" neither a method reference nor a qualified method invocation.
try
syn match javaOperator "\%(\%(::\|\.\)[[:space:]\n]*\)\@80<!\<yield\>"
let s:ff.Peek = s:ff.LeftConstant
catch /\<E59:/
call s:ReportOnce(v:exception)
syn match javaOperator "\%(\%(::\|\.\)[[:space:]\n]*\)\@<!\<yield\>"
let s:ff.Peek = s:ff.RightConstant
endtry
syn keyword javaType boolean char byte short int long float double
syn keyword javaType void
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
syn keyword javaStatement return
syn keyword javaStorageClass static synchronized transient volatile strictfp serializable
syn keyword javaExceptions throw try catch finally
syn keyword javaAssert assert
syn keyword javaMethodDecl throws
" Differentiate a "MyClass.class" literal from the keyword "class".
syn match javaTypedef "\.\s*\<class\>"ms=s+1
syn keyword javaClassDecl enum extends implements interface
syn match javaClassDecl "\<permits\>\%(\s*(\)\@!"
syn match javaClassDecl "\<record\>\%(\s*(\)\@!"
syn match javaClassDecl "^class\>"
syn match javaClassDecl "[^.]\s*\<class\>"ms=s+1
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 https://github.com/vim/vim/commit/4052474a1bd2fe756bc7dc596d29d0d7581e35ae Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-15 18:32:55 -07:00
syn match javaAnnotation "@\%(\K\k*\.\)*\K\k*\>"
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn region javaAnnotation transparent matchgroup=javaAnnotationStart start=/@\%(\K\k*\.\)*\K\k*(/ end=/)/ skip=/\/\*.\{-}\*\/\|\/\/.*$/ contains=javaAnnotation,javaParenT,javaBlock,javaString,javaBoolean,javaNumber,javaTypedef,javaComment,javaLineComment
syn match javaClassDecl "@interface\>"
syn keyword javaBranch break continue nextgroup=javaUserLabelRef skipwhite
syn match javaUserLabelRef "\k\+" contained
syn match javaVarArg "\.\.\."
syn keyword javaScopeDecl public protected private
syn keyword javaConceptKind abstract final
syn match javaConceptKind "\<non-sealed\>"
syn match javaConceptKind "\<sealed\>\%(\s*(\)\@!"
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
syn match javaConceptKind "\<default\>\%(\s*\%(:\|->\)\)\@!"
" Note that a "module-info" file will be recognised with an arbitrary
" file extension (or no extension at all) so that more than one such
" declaration for the same Java module can be maintained for modular
" testing in a project without attendant confusion for IDEs, with the
" ".java\=" extension used for a production version and an arbitrary
" extension used for a testing version.
let s:module_info_cur_buf = fnamemodify(bufname("%"), ":t") =~ '^module-info\%(\.class\>\)\@!'
lockvar s:module_info_cur_buf
if !(v:version < 704)
" Request the new regexp engine for [:upper:] and [:lower:].
let [s:ff.Engine, s:ff.UpperCase, s:ff.LowerCase] = repeat([s:ff.LeftConstant], 3)
else
" XXX: \C\<[^a-z0-9]\k*\> rejects "type", but matches "τύπος".
" XXX: \C\<[^A-Z0-9]\k*\> rejects "Method", but matches "Μέθοδος".
let [s:ff.Engine, s:ff.UpperCase, s:ff.LowerCase] = repeat([s:ff.RightConstant], 3)
endif
" Java modules (since Java 9, for "module-info.java" file).
if s:module_info_cur_buf
syn keyword javaModuleStorageClass module transitive
syn keyword javaModuleStmt open requires exports opens uses provides
syn keyword javaModuleExternal to with
endif
if exists("java_highlight_java_lang_ids")
let java_highlight_all=1
endif
if exists("java_highlight_all") || exists("java_highlight_java") || exists("java_highlight_java_lang")
" java.lang.*
"
" The keywords of javaR_JavaLang, javaC_JavaLang, javaE_JavaLang,
" and javaX_JavaLang are sub-grouped according to the Java version
" of their introduction, and sub-group keywords (that is, class
" names) are arranged in alphabetical order, so that future newer
" keywords can be pre-sorted and appended without disturbing
" the current keyword placement. The below _match_es follow suit.
syn keyword javaR_JavaLang ArithmeticException ArrayIndexOutOfBoundsException ArrayStoreException ClassCastException IllegalArgumentException IllegalMonitorStateException IllegalThreadStateException IndexOutOfBoundsException NegativeArraySizeException NullPointerException NumberFormatException RuntimeException SecurityException StringIndexOutOfBoundsException IllegalStateException UnsupportedOperationException EnumConstantNotPresentException TypeNotPresentException IllegalCallerException LayerInstantiationException WrongThreadException MatchException
syn cluster javaClasses add=javaR_JavaLang
hi def link javaR_JavaLang javaR_Java
" Member enumerations:
exec 'syn match javaC_JavaLang "\%(\<Thread\.\)\@' . s:ff.Peek('7', '') . '<=\<State\>"'
exec 'syn match javaC_JavaLang "\%(\<Character\.\)\@' . s:ff.Peek('10', '') . '<=\<UnicodeScript\>"'
exec 'syn match javaC_JavaLang "\%(\<ProcessBuilder\.Redirect\.\)\@' . s:ff.Peek('24', '') . '<=\<Type\>"'
exec 'syn match javaC_JavaLang "\%(\<StackWalker\.\)\@' . s:ff.Peek('12', '') . '<=\<Option\>"'
exec 'syn match javaC_JavaLang "\%(\<System\.Logger\.\)\@' . s:ff.Peek('14', '') . '<=\<Level\>"'
" Member classes:
exec 'syn match javaC_JavaLang "\%(\<Character\.\)\@' . s:ff.Peek('10', '') . '<=\<Subset\>"'
exec 'syn match javaC_JavaLang "\%(\<Character\.\)\@' . s:ff.Peek('10', '') . '<=\<UnicodeBlock\>"'
exec 'syn match javaC_JavaLang "\%(\<ProcessBuilder\.\)\@' . s:ff.Peek('15', '') . '<=\<Redirect\>"'
exec 'syn match javaC_JavaLang "\%(\<ModuleLayer\.\)\@' . s:ff.Peek('12', '') . '<=\<Controller\>"'
exec 'syn match javaC_JavaLang "\%(\<Runtime\.\)\@' . s:ff.Peek('8', '') . '<=\<Version\>"'
exec 'syn match javaC_JavaLang "\%(\<System\.\)\@' . s:ff.Peek('7', '') . '<=\<LoggerFinder\>"'
exec 'syn match javaC_JavaLang "\%(\<Enum\.\)\@' . s:ff.Peek('5', '') . '<=\<EnumDesc\>"'
syn keyword javaC_JavaLang Boolean Character Class ClassLoader Compiler Double Float Integer Long Math Number Object Process Runtime SecurityManager String StringBuffer Thread ThreadGroup Byte Short Void InheritableThreadLocal Package RuntimePermission ThreadLocal StrictMath StackTraceElement Enum ProcessBuilder StringBuilder ClassValue Module ModuleLayer StackWalker Record
syn match javaC_JavaLang "\<System\>" " See javaDebug.
" As of JDK 21, java.lang.Compiler is no more (deprecated in JDK 9).
syn keyword javaLangDeprecated Compiler
syn cluster javaClasses add=javaC_JavaLang
hi def link javaC_JavaLang javaC_Java
syn keyword javaE_JavaLang AbstractMethodError ClassCircularityError ClassFormatError Error IllegalAccessError IncompatibleClassChangeError InstantiationError InternalError LinkageError NoClassDefFoundError NoSuchFieldError NoSuchMethodError OutOfMemoryError StackOverflowError ThreadDeath UnknownError UnsatisfiedLinkError VerifyError VirtualMachineError ExceptionInInitializerError UnsupportedClassVersionError AssertionError BootstrapMethodError
syn cluster javaClasses add=javaE_JavaLang
hi def link javaE_JavaLang javaE_Java
syn keyword javaX_JavaLang ClassNotFoundException CloneNotSupportedException Exception IllegalAccessException InstantiationException InterruptedException NoSuchMethodException Throwable NoSuchFieldException ReflectiveOperationException
syn cluster javaClasses add=javaX_JavaLang
hi def link javaX_JavaLang javaX_Java
hi def link javaR_Java javaR_
hi def link javaC_Java javaC_
hi def link javaE_Java javaE_
hi def link javaX_Java javaX_
hi def link javaX_ javaExceptions
hi def link javaR_ javaExceptions
hi def link javaE_ javaExceptions
hi def link javaC_ javaConstant
syn keyword javaLangObject clone equals finalize getClass hashCode
syn keyword javaLangObject notify notifyAll toString wait
hi def link javaLangObject javaConstant
endif
if filereadable(expand("<sfile>:p:h") . "/javaid.vim")
source <sfile>:p:h/javaid.vim
endif
if exists("java_space_errors")
if !exists("java_no_trail_space_error")
syn match javaSpaceError "\s\+$"
endif
if !exists("java_no_tab_space_error")
syn match javaSpaceError " \+\t"me=e-1
endif
endif
exec 'syn match javaUserLabel "^\s*\<\K\k*\>\%(\<default\>\)\@' . s:ff.Peek('7', '') . '<!\s*:"he=e-1'
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
syn region javaLabelRegion transparent matchgroup=javaLabel start="\<case\>" matchgroup=NONE end=":\|->" contains=javaLabelCastType,javaLabelNumber,javaCharacter,javaString,javaConstant,@javaClasses,javaLabelDefault,javaLabelVarType,javaLabelWhenClause
syn region javaLabelRegion transparent matchgroup=javaLabel start="\<default\>\%(\s*\%(:\|->\)\)\@=" matchgroup=NONE end=":\|->" oneline
" Consider grouped _default_ _case_ labels, i.e.
" case null, default ->
" case null: default:
syn keyword javaLabelDefault contained default
syn keyword javaLabelVarType contained var
syn keyword javaLabelCastType contained char byte short int
" Allow for the contingency of the enclosing region not being able to
" _keep_ its _end_, e.g. case ':':.
syn region javaLabelWhenClause contained transparent matchgroup=javaLabel start="\<when\>" matchgroup=NONE end=":"me=e-1 end="->"me=e-2 contains=TOP,javaExternal,javaLambdaDef
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
syn match javaLabelNumber contained "\<0\>[lL]\@!"
syn match javaLabelNumber contained "\<\%(0\%([xX]\x\%(_*\x\)*\|_*\o\%(_*\o\)*\|[bB][01]\%(_*[01]\)*\)\|[1-9]\%(_*\d\)*\)\>[lL]\@!"
hi def link javaLabelDefault javaLabel
hi def link javaLabelVarType javaOperator
hi def link javaLabelNumber javaNumber
hi def link javaLabelCastType javaType
" Comments
syn keyword javaTodo contained TODO FIXME XXX
if exists("java_comment_strings")
syn region javaCommentString contained start=+"+ end=+"+ end=+$+ end=+\*/+me=s-1,he=s-1 contains=javaSpecial,javaCommentStar,javaSpecialChar,@Spell
syn region javaCommentString contained start=+"""[ \t\x0c\r]*$+hs=e+1 end=+"""+he=s-1 contains=javaSpecial,javaCommentStar,javaSpecialChar,@Spell,javaSpecialError,javaTextBlockError
syn region javaComment2String contained start=+"+ end=+$\|"+ contains=javaSpecial,javaSpecialChar,@Spell
syn match javaCommentCharacter contained "'\\[^']\{1,6\}'" contains=javaSpecialChar
syn match javaCommentCharacter contained "'\\''" contains=javaSpecialChar
syn match javaCommentCharacter contained "'[^\\]'"
syn cluster javaCommentSpecial add=javaCommentString,javaCommentCharacter,javaNumber,javaStrTempl
syn cluster javaCommentSpecial2 add=javaComment2String,javaCommentCharacter,javaNumber,javaStrTempl
endif
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn region javaComment matchgroup=javaCommentStart start="/\*" end="\*/" contains=@javaCommentSpecial,javaTodo,javaCommentError,javaSpaceError,@Spell fold
syn match javaCommentStar contained "^\s*\*[^/]"me=e-1
syn match javaCommentStar contained "^\s*\*$"
syn match javaLineComment "//.*" contains=@javaCommentSpecial2,javaTodo,javaCommentMarkupTag,javaSpaceError,@Spell
2024-03-25 11:03:26 -07:00
syn match javaCommentMarkupTag contained "@\%(end\|highlight\|link\|replace\|start\)\>" nextgroup=javaCommentMarkupTagAttr,javaSpaceError skipwhite
syn match javaCommentMarkupTagAttr contained "\<region\>" nextgroup=javaCommentMarkupTagAttr,javaSpaceError skipwhite
exec 'syn region javaCommentMarkupTagAttr contained transparent matchgroup=htmlArg start=/\<\%(re\%(gex\|gion\|placement\)\|substring\|t\%(arget\|ype\)\)\%(\s*=\)\@=/ matchgroup=htmlString end=/\%(=\s*\)\@' . s:ff.Peek('80', '') . '<=\%("[^"]\+"\|' . "\x27[^\x27]\\+\x27" . '\|\%([.-]\|\k\)\+\)/ nextgroup=javaCommentMarkupTagAttr,javaSpaceError skipwhite oneline'
hi def link javaCommentMarkupTagAttr htmlArg
hi def link javaCommentString javaString
hi def link javaComment2String javaString
hi def link javaCommentCharacter javaCharacter
2024-03-25 11:03:26 -07:00
syn match javaCommentError contained "/\*"me=e-1 display
hi def link javaCommentError javaError
hi def link javaCommentStart javaComment
if !exists("java_ignore_javadoc") && main_syntax != 'jsp'
syntax case ignore
" Include HTML syntax coloring for Javadoc comments.
syntax include @javaHtml syntax/html.vim
unlet b:current_syntax
" HTML enables spell checking for all text that is not in a syntax
" item (:syntax spell toplevel); instead, limit spell checking to
" items matchable with syntax groups containing the @Spell cluster.
try
syntax spell default
catch /\<E390:/
call s:ReportOnce(v:exception)
endtry
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn region javaDocComment start="/\*\*" end="\*/" keepend contains=javaCommentTitle,@javaHtml,javaDocTags,javaDocSeeTag,javaDocCodeTag,javaDocSnippetTag,javaTodo,javaCommentError,javaSpaceError,@Spell fold
exec 'syn region javaCommentTitle contained matchgroup=javaDocComment start="/\*\*" matchgroup=javaCommentTitle end="\.$" end="\.[ \t\r]\@=" end="\%(^\s*\**\s*\)\@' . s:ff.Peek('80', '') . '<=@"me=s-2,he=s-1 end="\*/"me=s-1,he=s-1 contains=@javaHtml,javaCommentStar,javaTodo,javaCommentError,javaSpaceError,@Spell,javaDocTags,javaDocSeeTag,javaDocCodeTag,javaDocSnippetTag'
2024-03-25 11:03:26 -07:00
syn region javaCommentTitle contained matchgroup=javaDocComment start="/\*\*\s*\r\=\n\=\s*\**\s*\%({@return\>\)\@=" matchgroup=javaCommentTitle end="}\%(\s*\.*\)*" contains=@javaHtml,javaCommentStar,javaTodo,javaCommentError,javaSpaceError,@Spell,javaDocTags,javaDocSeeTag,javaDocCodeTag,javaDocSnippetTag
syn region javaDocTags contained start="{@\%(li\%(teral\|nk\%(plain\)\=\)\|inherit[Dd]oc\|doc[rR]oot\|value\)\>" end="}"
2024-03-25 11:03:26 -07:00
syn match javaDocTags contained "@\%(param\|exception\|throws\|since\)\s\+\S\+" contains=javaDocParam
syn match javaDocParam contained "\s\S\+"
syn match javaDocTags contained "@\%(version\|author\|return\|deprecated\|serial\%(Field\|Data\)\=\)\>"
syn region javaDocSeeTag contained matchgroup=javaDocTags start="@see\s\+" matchgroup=NONE end="\_."re=e-1 contains=javaDocSeeTagParam
syn match javaDocSeeTagParam contained @"\_[^"]\+"\|<a\s\+\_.\{-}</a>\|\%(\k\|\.\)*\%(#\k\+\%((\_[^)]*)\)\=\)\=@ contains=@javaHtml extend
syn region javaCodeSkipBlock contained transparent start="{\%(@code\>\)\@!" end="}" contains=javaCodeSkipBlock,javaDocCodeTag
syn region javaDocCodeTag contained start="{@code\>" end="}" contains=javaDocCodeTag,javaCodeSkipBlock
exec 'syn region javaDocSnippetTagAttr contained transparent matchgroup=htmlArg start=/\<\%(class\|file\|id\|lang\|region\)\%(\s*=\)\@=/ matchgroup=htmlString end=/:$/ end=/\%(=\s*\)\@' . s:ff.Peek('80', '') . '<=\%("[^"]\+"\|' . "\x27[^\x27]\\+\x27" . '\|\%([.\\/-]\|\k\)\+\)/ nextgroup=javaDocSnippetTagAttr skipwhite skipnl'
syn region javaSnippetSkipBlock contained transparent start="{\%(@snippet\>\)\@!" end="}" contains=javaSnippetSkipBlock,javaDocSnippetTag,javaCommentMarkupTag
syn region javaDocSnippetTag contained start="{@snippet\>" end="}" contains=javaDocSnippetTag,javaSnippetSkipBlock,javaDocSnippetTagAttr,javaCommentMarkupTag
syntax case match
endif
" match the special comment /**/
syn match javaComment "/\*\*/"
" Strings and constants
syn match javaSpecialError contained "\\."
syn match javaSpecialCharError contained "[^']"
" Escape Sequences (JLS-17, §3.10.7):
syn match javaSpecialChar contained "\\\%(u\x\x\x\x\|[0-3]\o\o\|\o\o\=\|[bstnfr"'\\]\)"
syn region javaString start=+"+ end=+"+ end=+$+ contains=javaSpecialChar,javaSpecialError,@Spell
syn region javaString start=+"""[ \t\x0c\r]*$+hs=e+1 end=+"""+he=s-1 contains=javaSpecialChar,javaSpecialError,javaTextBlockError,@Spell
syn match javaTextBlockError +"""\s*"""+
syn region javaStrTemplEmbExp contained matchgroup=javaStrTempl start="\\{" end="}" contains=TOP
exec 'syn region javaStrTempl start=+\%(\.[[:space:]\n]*\)\@' . s:ff.Peek('80', '') . '<="+ end=+"+ contains=javaStrTemplEmbExp,javaSpecialChar,javaSpecialError,@Spell'
exec 'syn region javaStrTempl start=+\%(\.[[:space:]\n]*\)\@' . s:ff.Peek('80', '') . '<="""[ \t\x0c\r]*$+hs=e+1 end=+"""+he=s-1 contains=javaStrTemplEmbExp,javaSpecialChar,javaSpecialError,javaTextBlockError,@Spell'
syn match javaCharacter "'[^']*'" contains=javaSpecialChar,javaSpecialCharError
syn match javaCharacter "'\\''" contains=javaSpecialChar
syn match javaCharacter "'[^\\]'"
" Integer literals (JLS-17, §3.10.1):
syn keyword javaNumber 0 0l 0L
syn match javaNumber "\<\%(0\%([xX]\x\%(_*\x\)*\|_*\o\%(_*\o\)*\|[bB][01]\%(_*[01]\)*\)\|[1-9]\%(_*\d\)*\)[lL]\=\>"
" Decimal floating-point literals (JLS-17, §3.10.2):
" Against "\<\d\+\>\.":
syn match javaNumber "\<\d\%(_*\d\)*\."
syn match javaNumber "\%(\<\d\%(_*\d\)*\.\%(\d\%(_*\d\)*\)\=\|\.\d\%(_*\d\)*\)\%([eE][-+]\=\d\%(_*\d\)*\)\=[fFdD]\=\>"
syn match javaNumber "\<\d\%(_*\d\)*[eE][-+]\=\d\%(_*\d\)*[fFdD]\=\>"
syn match javaNumber "\<\d\%(_*\d\)*\%([eE][-+]\=\d\%(_*\d\)*\)\=[fFdD]\>"
" Hexadecimal floating-point literals (JLS-17, §3.10.2):
syn match javaNumber "\<0[xX]\%(\x\%(_*\x\)*\.\=\|\%(\x\%(_*\x\)*\)\=\.\x\%(_*\x\)*\)[pP][-+]\=\d\%(_*\d\)*[fFdD]\=\>"
" Unicode characters
syn match javaSpecial "\\u\x\x\x\x"
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 https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3 Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-24 14:44:01 -07:00
" Method declarations (JLS-17, §8.4.3, §8.4.4, §9.4).
if exists("java_highlight_functions")
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 https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3 Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-24 14:44:01 -07:00
syn cluster javaFuncParams contains=javaAnnotation,@javaClasses,javaType,javaVarArg,javaComment,javaLineComment
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. https://github.com/vim/vim/commit/c4d0c8c81245918632a9d3c2c20a390546fad065 Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-29 14:44:53 -07:00
if java_highlight_functions =~# '^indent[1-8]\=$'
let s:last = java_highlight_functions[-1 :]
let s:indent = s:last != 't' ? repeat("\x20", s:last) : "\t"
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 https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3 Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-24 14:44:01 -07:00
syn cluster javaFuncParams add=javaScopeDecl,javaConceptKind,javaStorageClass,javaExternal
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. https://github.com/vim/vim/commit/c4d0c8c81245918632a9d3c2c20a390546fad065 Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-29 14:44:53 -07:00
" Try to not match other type members, initialiser blocks, enum
" constants (JLS-17, §8.9.1), and constructors (JLS-17, §8.1.7):
" at any _conventional_ indentation, skip over all fields with
" "[^=]*", all records with "\<record\s", and let the "*Skip*"
" definitions take care of constructor declarations and enum
" constants (with no support for @Foo(value = "bar")).
exec 'syn region javaFuncDef start=+^' . s:indent . '\%(<[^>]\+>\+\s\+\|\%(\%(@\%(\K\k*\.\)*\K\k*\>\)\s\+\)\+\)\=\%(\<\K\k*\>\.\)*\K\k*\>[^=]*\%(\<record\)\@' . s:ff.Peek('6', '') . '<!\s\K\k*\s*(+ end=+)+ contains=@javaFuncParams'
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. https://github.com/vim/vim/commit/c4d0c8c81245918632a9d3c2c20a390546fad065 Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-29 14:44:53 -07:00
" As long as package-private constructors cannot be matched with
" javaFuncDef, do not look with javaConstructorSkipDeclarator for
" them.
exec 'syn match javaConstructorSkipDeclarator transparent +^' . s:indent . '\%(\%(@\%(\K\k*\.\)*\K\k*\>\)\s\+\)*p\%(ublic\|rotected\|rivate\)\s\+\%(<[^>]\+>\+\s\+\)\=\K\k*\s*\ze(+ contains=javaAnnotation,javaScopeDecl'
exec 'syn match javaEnumSkipArgumentativeConstant transparent +^' . s:indent . '\%(\%(@\%(\K\k*\.\)*\K\k*\>\)\s\+\)*\K\k*\s*\ze(+ contains=javaAnnotation'
unlet s:indent s:last
else
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 https://github.com/vim/vim/commit/4052474a1bd2fe756bc7dc596d29d0d7581e35ae Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-15 18:32:55 -07:00
" This is the "style" variant (:help ft-java-syntax).
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 https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3 Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-04-24 14:44:01 -07:00
syn cluster javaFuncParams add=javaScopeDecl,javaConceptKind,javaStorageClass,javaExternal
" Match arbitrarily indented camelCasedName method declarations.
" Match: [@ɐ] [abstract] [<α, β>] Τʬ[<γ>][[][]] μʭʭ(/* ... */);
exec 'syn region javaFuncDef start=/' . s:ff.Engine('\%#=2', '') . '^\s\+\%(\%(@\%(\K\k*\.\)*\K\k*\>\)\s\+\)*\%(p\%(ublic\|rotected\|rivate\)\s\+\)\=\%(\%(abstract\|default\)\s\+\|\%(\%(final\|\%(native\|strictfp\)\|s\%(tatic\|ynchronized\)\)\s\+\)*\)\=\%(<.*[[:space:]-]\@' . s:ff.Peek('1', '') . '<!>\s\+\)\=\%(void\|\%(b\%(oolean\|yte\)\|char\|short\|int\|long\|float\|double\|\%(\<\K\k*\>\.\)*\<' . s:ff.UpperCase('[$_[:upper:]]', '[^a-z0-9]') . '\k*\>\%(<[^(){}]*[[:space:]-]\@' . s:ff.Peek('1', '') . '<!>\)\=\)\%(\[\]\)*\)\s\+\<' . s:ff.LowerCase('[$_[:lower:]]', '[^A-Z0-9]') . '\k*\>\s*(/ end=/)/ skip=/\/\*.\{-}\*\/\|\/\/.*$/ contains=@javaFuncParams'
endif
endif
if exists("java_highlight_debug")
" Strings and constants
syn match javaDebugSpecial contained "\\\%(u\x\x\x\x\|[0-3]\o\o\|\o\o\=\|[bstnfr"'\\]\)"
syn region javaDebugString contained start=+"+ end=+"+ contains=javaDebugSpecial
syn region javaDebugString contained start=+"""[ \t\x0c\r]*$+hs=e+1 end=+"""+he=s-1 contains=javaDebugSpecial,javaDebugTextBlockError
" The highlight groups of java{StrTempl,Debug{,Paren,StrTempl}}\,
" share one colour by default. Do not conflate unrelated parens.
syn region javaDebugStrTemplEmbExp contained matchgroup=javaDebugStrTempl start="\\{" end="}" contains=javaComment,javaLineComment,javaDebug\%(Paren\)\@!.*
exec 'syn region javaDebugStrTempl contained start=+\%(\.[[:space:]\n]*\)\@' . s:ff.Peek('80', '') . '<="+ end=+"+ contains=javaDebugStrTemplEmbExp,javaDebugSpecial'
exec 'syn region javaDebugStrTempl contained start=+\%(\.[[:space:]\n]*\)\@' . s:ff.Peek('80', '') . '<="""[ \t\x0c\r]*$+hs=e+1 end=+"""+he=s-1 contains=javaDebugStrTemplEmbExp,javaDebugSpecial,javaDebugTextBlockError'
syn match javaDebugTextBlockError contained +"""\s*"""+
syn match javaDebugCharacter contained "'[^\\]'"
syn match javaDebugSpecialCharacter contained "'\\.'"
syn match javaDebugSpecialCharacter contained "'\\''"
syn keyword javaDebugNumber contained 0 0l 0L
syn match javaDebugNumber contained "\<\d\%(_*\d\)*\."
syn match javaDebugNumber contained "\<\%(0\%([xX]\x\%(_*\x\)*\|_*\o\%(_*\o\)*\|[bB][01]\%(_*[01]\)*\)\|[1-9]\%(_*\d\)*\)[lL]\=\>"
syn match javaDebugNumber contained "\%(\<\d\%(_*\d\)*\.\%(\d\%(_*\d\)*\)\=\|\.\d\%(_*\d\)*\)\%([eE][-+]\=\d\%(_*\d\)*\)\=[fFdD]\=\>"
syn match javaDebugNumber contained "\<\d\%(_*\d\)*[eE][-+]\=\d\%(_*\d\)*[fFdD]\=\>"
syn match javaDebugNumber contained "\<\d\%(_*\d\)*\%([eE][-+]\=\d\%(_*\d\)*\)\=[fFdD]\>"
syn match javaDebugNumber contained "\<0[xX]\%(\x\%(_*\x\)*\.\=\|\%(\x\%(_*\x\)*\)\=\.\x\%(_*\x\)*\)[pP][-+]\=\d\%(_*\d\)*[fFdD]\=\>"
syn keyword javaDebugBoolean contained true false
syn keyword javaDebugType contained null this super
syn region javaDebugParen start=+(+ end=+)+ contained contains=javaDebug.*,javaDebugParen
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 https://github.com/vim/vim/commit/4052474a1bd2fe756bc7dc596d29d0d7581e35ae Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-15 18:32:55 -07:00
" To make this work, define the highlighting for these groups.
syn match javaDebug "\<System\.\%(out\|err\)\.print\%(ln\)\=\s*("me=e-1 contains=javaDebug.* nextgroup=javaDebugParen
" FIXME: What API does "p" belong to?
" syn match javaDebug "\<p\s*("me=e-1 contains=javaDebug.* nextgroup=javaDebugParen
syn match javaDebug "\<\K\k*\.printStackTrace\s*("me=e-1 contains=javaDebug.* nextgroup=javaDebugParen
" FIXME: What API do "trace*" belong to?
" syn match javaDebug "\<trace[SL]\=\s*("me=e-1 contains=javaDebug.* nextgroup=javaDebugParen
hi def link javaDebug Debug
hi def link javaDebugString DebugString
hi def link javaDebugStrTempl Macro
hi def link javaDebugTextBlockError Error
hi def link javaDebugType DebugType
hi def link javaDebugBoolean DebugBoolean
hi def link javaDebugNumber Debug
hi def link javaDebugSpecial DebugSpecial
hi def link javaDebugSpecialCharacter DebugSpecial
hi def link javaDebugCharacter DebugString
hi def link javaDebugParen Debug
hi def link DebugString String
hi def link DebugSpecial Special
hi def link DebugBoolean Boolean
hi def link DebugType Type
endif
if exists("java_mark_braces_in_parens_as_errors")
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn match javaInParen contained "[{}]"
hi def link javaInParen javaError
endif
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
" Try not to fold top-level-type bodies under assumption that there is
" but one such body.
exec 'syn region javaBlock transparent start="\%(^\|^\S[^:]\+\)\@' . s:ff.Peek('120', '') . '<!{" end="}" fold'
" catch errors caused by wrong parenthesis
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn region javaParenT transparent matchgroup=javaParen start="(" end=")" contains=@javaTop,javaInParen,javaParenT1
syn region javaParenT1 transparent matchgroup=javaParen1 start="(" end=")" contains=@javaTop,javaInParen,javaParenT2 contained
syn region javaParenT2 transparent matchgroup=javaParen2 start="(" end=")" contains=@javaTop,javaInParen,javaParenT contained
syn match javaParenError ")"
" catch errors caused by wrong square parenthesis
syn region javaParenT transparent matchgroup=javaParen start="\[" end="\]" contains=@javaTop,javaParenT1
syn region javaParenT1 transparent matchgroup=javaParen1 start="\[" end="\]" contains=@javaTop,javaParenT2 contained
syn region javaParenT2 transparent matchgroup=javaParen2 start="\[" end="\]" contains=@javaTop,javaParenT contained
syn match javaParenError "\]"
hi def link javaParenError javaError
" Lambda expressions (JLS-17, §15.27).
if exists("java_highlight_functions")
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 https://github.com/vim/vim/commit/4052474a1bd2fe756bc7dc596d29d0d7581e35ae Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-04-15 18:32:55 -07:00
" Make ()-matching definitions after the parenthesis error catcher.
"
" Match: ([@A [@B ...] final] var a[, var b, ...]) ->
" | ([@A [@B ...] final] T[<α>][[][]] a[, T b, ...]) ->
" There is no recognition of expressions interspersed with comments
" or of expressions whose parameterised parameter types are written
" across multiple lines.
exec 'syn match javaLambdaDef "\k\@' . s:ff.Peek('4', '') . '<!([[:space:]\n]*\%(\%(@\%(\K\k*\.\)*\K\k*\>\%((\_.\{-1,})\)\{-,1}[[:space:]\n]\+\)*\%(final[[:space:]\n]\+\)\=\%(\<\K\k*\>\.\)*\<\K\k*\>\%(<[^(){}]*[[:space:]-]\@' . s:ff.Peek('1', '') . '<!>\)\=\%(\%(\%(\[\]\)\+\|\.\.\.\)\)\=[[:space:]\n]\+\<\K\k*\>\%(\[\]\)*\%(,[[:space:]\n]*\)\=\)\+)[[:space:]\n]*->" contains=javaAnnotation,javaParamModifier,javaLambdaVarType,javaType,@javaClasses,javaVarArg'
" Match: () ->
" | (a[, b, ...]) ->
exec 'syn match javaLambdaDef "\k\@' . s:ff.Peek('4', '') . '<!([[:space:]\n]*\%(\<\K\k*\>\%(,[[:space:]\n]*\)\=\)*)[[:space:]\n]*->"'
" Match: a ->
exec 'syn match javaLambdaDef "\<\K\k*\>\%(\<default\>\)\@' . s:ff.Peek('7', '') . '<![[:space:]\n]*->"'
syn keyword javaParamModifier contained final
hi def link javaParamModifier javaConceptKind
syn keyword javaLambdaVarType contained var
hi def link javaLambdaVarType javaOperator
endif
" The @javaTop cluster comprises non-contained Java syntax groups.
" Note that the syntax file "aidl.vim" relies on its availability.
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
syn cluster javaTop contains=TOP,javaDocComment,javaBlock,javaParenError,javaParenT
if !exists("java_minlines")
let java_minlines = 10
endif
2024-03-25 11:03:26 -07:00
" Note that variations of a /*/ balanced comment, e.g., /*/*/, /*//*/,
" /* /*/, /* /*/, etc., may have their rightmost /*/ part accepted
" as a comment start by ':syntax sync ccomment'; consider alternatives
" to make synchronisation start further towards file's beginning by
" bumping up g:java_minlines or issuing ':syntax sync fromstart' or
" preferring &foldmethod set to 'syntax'.
exec "syn sync ccomment javaComment minlines=" . java_minlines
" The default highlighting.
hi def link javaLambdaDef Function
hi def link javaFuncDef Function
hi def link javaVarArg Function
hi def link javaBranch Conditional
hi def link javaUserLabelRef javaUserLabel
hi def link javaLabel Label
hi def link javaUserLabel Label
hi def link javaConditional Conditional
hi def link javaRepeat Repeat
hi def link javaExceptions Exception
hi def link javaAssert Statement
hi def link javaStorageClass StorageClass
hi def link javaMethodDecl javaStorageClass
hi def link javaClassDecl javaStorageClass
hi def link javaScopeDecl javaStorageClass
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 https://github.com/vim/vim/commit/9ecf02cd5f5feabe096f66cd5f503a822c78793f Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
2024-02-29 01:36:07 -07:00
hi def link javaConceptKind NonText
hi def link javaBoolean Boolean
hi def link javaSpecial Special
hi def link javaSpecialError Error
hi def link javaSpecialCharError Error
hi def link javaString String
hi def link javaStrTempl Macro
hi def link javaCharacter Character
hi def link javaSpecialChar SpecialChar
hi def link javaNumber Number
hi def link javaError Error
hi def link javaTextBlockError Error
hi def link javaStatement Statement
hi def link javaOperator Operator
hi def link javaComment Comment
hi def link javaDocComment Comment
hi def link javaLineComment Comment
hi def link javaConstant Constant
hi def link javaTypedef Typedef
hi def link javaTodo Todo
hi def link javaAnnotation PreProc
hi def link javaAnnotationStart javaAnnotation
hi def link javaCommentTitle SpecialComment
hi def link javaDocTags Special
hi def link javaDocCodeTag Special
hi def link javaDocSnippetTag Special
hi def link javaDocParam Function
hi def link javaDocSeeTagParam Function
hi def link javaCommentStar javaComment
hi def link javaType Type
hi def link javaExternal Include
hi def link htmlComment Special
hi def link htmlCommentPart Special
hi def link htmlArg Type
hi def link htmlString String
hi def link javaSpaceError Error
if s:module_info_cur_buf
hi def link javaModuleStorageClass StorageClass
hi def link javaModuleStmt Statement
hi def link javaModuleExternal Include
endif
let b:current_syntax = "java"
if main_syntax == 'java'
unlet main_syntax
endif
let b:spell_options = "contained"
let &cpo = s:cpo_save
unlet s:module_info_cur_buf s:ff s:cpo_save
vim-patch:371bab0: runtime(java): Fold multi-line comments with the syntax kind of &fdm (vim/vim#15016) 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. https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-06-16 02:29:01 -07:00
" See ":help vim9-mix".
if !has("vim9script")
finish
endif
def! s:JavaSyntaxFoldTextExpr(): string
return getline(v:foldstart) !~ '/\*\+\s*$'
? foldtext()
: printf('+-%s%3d lines: ',
v:folddashes,
(v:foldend - v:foldstart + 1)) ..
getline(v:foldstart + 1)
enddef
setlocal foldtext=s:JavaSyntaxFoldTextExpr()
delfunction! g:JavaSyntaxFoldTextExpr
" vim: sw=2 ts=8 noet sta