aniani/vim
0
0
Fork 1
mirror of https://github.com/vim/vim.git synced 2025-07-04 23:07:33 -04:00
Code
vim/runtime/syntax/testdir/dumps/java_methods_style_00.dump

21 lines
1.4 KiB
Plaintext
Raw Normal View History

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: #14620 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
>/+0#0000e05#ffffff0@1| |V|I|M|_|T|E|S|T|_|S|E|T|U|P| |l|e|t| |g|:|j|a|v|a|_|h|i|g|h|l|i|g|h|t|_|f|u|n|c|t|i|o|n|s| |=| |'|s|t|y|l|e|'| +0#0000000&@16
@75
@75
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
|i+0#e000e06&|m|p|o|r|t| +0#0000000&|j|a|v|a|.|l|a|n|g|.|a|n@1|o|t|a|t|i|o|n|.|E|l|e|m|e|n|t|T|y|p|e|;| @34
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: #14620 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
|i+0#e000e06&|m|p|o|r|t| +0#0000000&|j|a|v|a|.|l|a|n|g|.|a|n@1|o|t|a|t|i|o|n|.|T|a|r|g|e|t|;| @39
@75
|a+0#4040ff13&|b|s|t|r|a|c|t| +0#0000000&|c+0#00e0003&|l|a|s@1| +0#0000000&|S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s| @42
|{+0#00e0e07&| +0#0000000&@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
@4|/+0#0000e05&@1| |T|Y|P|E|S|.| +0#0000000&@61
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: #14620 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
@4|r+0#00e0003&|e|c|o|r|d| +0#0000000&|Τ|ʬ|<|α|>|(|α| |a|)| |{+0#00e0e07&| +0#0000000&|}+0#00e0e07&| +0#0000000&@49
@75
@4|e+0#00e0003&|n|u|m| +0#0000000&|𝓔| @64
@4|{+0#00e0e07&| +0#0000000&@69
@8|A|(|"+0#e000002&|𝕬|"|)+0#0000000&|,| |B|(|"+0#e000002&|𝕭|"|)+0#0000000&|,| |C|(|"+0#e000002&|𝕮|"|)+0#0000000&|,| |D|(|"+0#e000002&|𝕯|"|)+0#0000000&|,| @35
@8|E|(|"+0#e000002&|𝕰|"|)+0#0000000&|,| |F|(|"+0#e000002&|𝕱|"|)+0#0000000&|,| |G|(|"+0#e000002&|𝕲|"|)+0#0000000&|,| |H|(|"+0#e000002&|𝕳|"|)+0#0000000&|;| @35
@8|f+0#4040ff13&|i|n|a|l| +0#0000000&|S|t|r|i|n|g| |𝐬|;| @51
@8|p+0#00e0003&|r|i|v|a|t|e| +0#0000000&|𝓔|(|S|t|r|i|n|g| |𝐬|)| |{+0#00e0e07&| +0#0000000&|t+0#00e0003&|h|i|s|.+0#0000000&|𝐬| |=| |𝐬|;| |}+0#00e0e07&| +0#0000000&@31
@4|}+0#00e0e07&| +0#0000000&@69
@75
@57|1|,|1| @10|T|o|p|
Copy Permalink