aniani/vim
0
0
Fork 1
mirror of https://github.com/vim/vim.git synced 2025-10-31 09:57:14 -04:00
Code Activity
Files
a2aa921f767da17d4b619f41b7a1210c762c91e2
vim/runtime/syntax/testdir/dumps/java_methods_style_04.dump

21 lines
1.5 KiB
Plaintext
Raw Normal View History

runtime(java): Fold multi-line comments with the syntax kind of &fdm (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-16 09:42:55 +03:00
| +0&#ffffff0@3|{| |a|s|c|i@1|$|9|8|_|(|)|;| |}| @54
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
@75
runtime(java): Include element values in non-marker annotations (#14979) Make a formal definition for normal and single-element kinds of annotations that otherwise require for their containment to repeat each time all syntax groups that describe element values. Reference: https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.7 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-13 18:30:09 +03:00
@4|@+0#e000e06&|S|u|p@1|r|e|s@1|W|a|r|n|i|n|g|s|(|"+0#e000002&|s|t|r|i|c|t|f|p|"|)+0#e000e06&| +0#0000000&@41
runtime(java): Highlight javaConceptKind modifiers with StorageClass 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 #15238 closes: #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>
2024-09-15 19:53:50 +02:00
| +0#00e0e07&@3|p+0#00e0003&|r|o|t|e|c|t|e|d| +0#00e0e07&|s+0#00e0003&|t|a|t|i|c| +0#00e0e07&|f+0#00e0003&|i|n|a|l| +0#00e0e07&|s+0#00e0003&|y|n|c|h|r|o|n|i|z|e|d| +0#00e0e07&|s+0#00e0003&|t|r|i|c|t|f|p| +0#00e0e07&|<|α|,| |β|>| |Τ|ʬ|<|α|>|[|]| |μ|ʭ@1|$|9@1|_|(| +0#0000000&@2
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
| +0#00e0e07&@11|j|a|v|a|.|u|t|i|l|.|f|u|n|c|t|i|o|n|.|F|u|n|c|t|i|o|n|<|β|,| |Τ|ʬ|<|α|>|[|]|[|]|>| |ƒ|)| +0#0000000&@18
runtime(java): Fold multi-line comments with the syntax kind of &fdm (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-16 09:42:55 +03:00
@4>{| @69
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
@8|r+0#af5f00255&|e|t|u|r|n| +0#0000000&@60
@4|S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|.|<|α|,| |β|>|μ|ʭ@1|$|9|8|_|(|ƒ|)|[|0+0#e000002&|]+0#0000000&|;| @32
runtime(java): Fold multi-line comments with the syntax kind of &fdm (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-16 09:42:55 +03:00
@4|}| @69
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
@75
runtime(java): Fold multi-line comments with the syntax kind of &fdm (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-16 09:42:55 +03:00
| +0#00e0e07&@3|p+0#00e0003&|u|b|l|i|c| +0#00e0e07&|s+0#00e0003&|t|a|t|i|c| +0#00e0e07&|C|l|a|s@1|<|?|>| |c|l|a|s@1|L|o|c|k|(|)| +0#0000000&|{| |r+0#af5f00255&|e|t|u|r|n| +0#0000000&|S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|.|c+0#00e0003&|l|a|s@1|;+0#0000000&| |}|
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
@75
runtime(java): Include element values in non-marker annotations (#14979) Make a formal definition for normal and single-element kinds of annotations that otherwise require for their containment to repeat each time all syntax groups that describe element values. Reference: https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.7 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-13 18:30:09 +03:00
@4|@+0#e000e06&|O|v|e|r@1|i|d|e| +0#0000000&|@+0#e000e06&|S|u|p@1|r|e|s@1|W|a|r|n|i|n|g|s|(|"+0#e000002&|c|a|s|t|"|)+0#e000e06&| +0#0000000&@35
runtime(java): Fold multi-line comments with the syntax kind of &fdm (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-06-16 09:42:55 +03:00
| +0#00e0e07&@3|p+0#00e0003&|u|b|l|i|c| +0#00e0e07&|S|t|r|i|n|g| |t|o|S|t|r|i|n|g|(|)| +0#0000000&|{| |r+0#af5f00255&|e|t|u|r|n| +0#0000000&|(|S|t|r|i|n|g|)| |"+0#e000002&|S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|"|;+0#0000000&| |}| @5
|}| @73
runtime(java): Improve the recognition of the "indent" method declarations (#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. Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-29 21:24:35 +03:00
|~+0#4040ff13&| @73
|~| @73
|~| @73
|~| @73
| +0#0000000&@56|7|3|,|2|-|5| @7|B|o|t|
Copy Permalink