mirror of
https://github.com/vim/vim.git
synced 2025-07-26 11:04:33 -04:00
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: #14105 Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
Tests for syntax highlighting plugins ===================================== Summary: Files in the "input" directory are edited by Vim with syntax highlighting enabled. Screendumps are generated and compared with the expected screendumps in the "dumps" directory. This will uncover any character attributes that differ. Without any further setup a screendump is made at the top of the file (using _00.dump) and another one at the end of the file (using _99.dump). The dumps are normally 20 screen lines tall. When the screendumps are OK an empty "done/{name}" file is created. This avoids running the test again until "make clean" is used. Thus you can run "make test", see one test fail, try to fix the problem, then run "make test" again to only repeat the failing test. When a screendump differs it is stored in the "failed" directory. This allows for comparing it with the expected screendump, using a command like: let fname = '{name}_99.dump' call term_dumpdiff('failed/' .. fname, 'dumps/' .. fname) Creating a syntax plugin test ----------------------------- Create a source file in the language you want to test in the "input" directory. Make sure to include some interesting constructs with complicated highlighting. Use the filetype name as the base and a file name extension matching the filetype. Let's use Java as an example. The file would then be "input/java.java". If there is no further setup required, you can now run the tests: make test The first time this will fail with an error for a missing screendump. The newly created screendumps will be "failed/java_00.dump", "failed/java_01.dump", etc. You can inspect each with: call term_dumpload('failed/java_00.dump') call term_dumpload('failed/java_01.dump') ... call term_dumpload('failed/java_99.dump') If they look OK, move them to the "dumps" directory: :!mv failed/java_00.dump dumps :!mv failed/java_01.dump dumps ... :!mv failed/java_99.dump dumps If you now run the test again, it will succeed. Adjusting a syntax plugin test ------------------------------ If you make changes to the syntax plugin, you should add code to the input file to see the effect of these changes. So that the effect of the changes are covered by the test. You can follow these steps: 1. Edit the syntax plugin somewhere in your personal setup. Use a file somewhere to try out the changes. 2. Go to the directory where you have the Vim code checked out and replace the syntax plugin. Run the tests: "make test". Usually the tests will still pass, but if you fixed syntax highlighting that was already visible in the input file, carefully check that the changes in the screendump are intentional: let fname = '{name}_99.dump' call term_dumpdiff('failed/' .. fname, 'dumps/' .. fname) Fix the syntax plugin until the result is good. 2. Edit the input file for your language to add the items you have improved. (TODO: how to add another screendump?). Run the tests and you should get failures. Like with the previous step, carefully check that the new screendumps in the "failed" directory are good. Update the syntax plugin and the input file until the highlighting is good and you can see the effect of the syntax plugin improvements. Then move the screendumps from the "failed" to the "dumps" directory. Now "make test" should succeed. 3. Prepare a pull request with the modified files: - syntax plugin: syntax/{name}.vim - test input file: syntax/testdir/input/{name}.{ext} - test dump files: syntax/testdir/dumps/{name}_99.dump As an extra check you can temporarily put back the old syntax plugin and verify that the tests fail. Then you know your changes are covered by the test. TODO: run test for one specific filetype TODO: testing with various option values TODO: test syncing by jumping around