- unified bashStatement, kshStatement and shStatement as much as
possible
- separated builtin commands from external programs
- cleaned up kornshell flavor logic
- fixed alias syntax highlighting
- added test for bash alias syntax highlighting
- removed daemon keyword
closes: #18355
Signed-off-by: Bjoern Foersterling <bjoern.foersterling@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match the full :wincmd command syntax.
Allow for oneline assignment to Vim9 variables named winc[md].
Fixes#18368.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Include post operator whitespace in the Vim9 variable assignment
lookahead so that "redir =>" doesn't match as an assignment.
fixes: #18319closes: #18323
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The ellipsis literal (`...`) can be used in multiple contexts:
- Placeholders: `class Foo: ...`
- Containers: `Tuple[int, ...]`
- Assignments: `x = ...`
This is a trickier pattern to match because we can't rely on keyword
boundaries, so we instead look for exactly three dots (`...`).
This does mean that we will match the `...` portion of `x...x`, which
isn't valid Python syntax, but I think that's an acceptable trade-off
that avoids making this pattern much more complex.
Reference:
- https://docs.python.org/3/library/constants.html#Ellipsiscloses: #18107
Signed-off-by: Jon Parise <jon@indelible.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Fix matching of floats at the beginning of an f-string replacement
field, immediately after the opening brace.
The existing pattern, using `\zs`, cannot consume the already matched
`{` so use a lookbehind instead.
See comment: https://github.com/vim/vim/pull/17962#issuecomment-3201550443closes: #18220
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
No support is provided or planned for language recognition
in code snippets of documentation comments. Requesting to
load arbitrary syntax plugins with the aid of the concerned
variable is therefore wasteful in general and erroneous when
paired languages ":syn-include" one another without taking
steps to manage circularity.
related: #17308
related: #17220closes: #18172
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Highlight the iteration variable's type in Vim9 :for {var} loops.
Reported by Aliaksei Budavei.
fixes: #17961closes: #18163
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
bash 5.3 (released July 2025) added support for ${ cmd;} and
${|cmd;} style command substitution, which is similar (but not
identical) to ksh/mksh.
closes: #18084
Signed-off-by: Kevin Pulo <kevin.pulo@mongodb.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Highlight f-string replacement fields, including
- Comments
- Debugging flags
- Conversion fields
- Format specifications
- Delimiters
Syntax inside fields will be addressed in a separate commit.
related: #10734
related: #14033closes: #17784
Signed-off-by: Rob B <github@0x7e.net>
Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
And anticipate occasional multibyte line wrapping owing to:
> A poorly rendered line may otherwise become wrapped when enough of
> spurious U+FFFD (0xEF 0xBF 0xBD) characters claim more columns than
> are available (75) and then invalidate line correspondence under test.
Observe that for "vim_ex_command.vim" another workaround is
chosen: the long line containing an only multibyte character
near its EOL is conversely made longer by padding and moving
the character to a separate _tail_ part of the wrapped line.
That is, the _head_ part of the line is all ASCII characters
and the wrapped _tail_ part is a mix of various characters
whose total byte count is within bounds.
Other unmodified tracked files of interest:
java_lambda_expressions.java,
java_lambda_expressions_signature.java,
java_numbers.java,
markdown_conceal.markdown,
vim9_generic_function_example_set.vim
Also, remove stray U+FFFC (0xEF 0xBF 0xBC) characters.
Related to #16559 and #17704.
Reference:
0fde6aebdd/runtime/syntax/testdir/README.txt (L120-L123)closes: #17868
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match Neovim functions when has("nvim") is true or g:vimsyn_vim_features
contains "nvim".
Fixes issue #17884.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Ensure :map (and :abbreviate) terminate at | when included in :command
replacement strings containing commands separated by line continuations.
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
As reported in #16559, bytes of a multibyte character may
be written as separate U+FFFD characters in a ":terminal"
window on a busy machine. The testing facilities currently
offer an optional filtering step to be carried out between
reading and comparing the contents of two screendump files
for each such file. This filtering has been resorted to
(#14767 and #16560) in an attempt to unconditionally replace
known non-Latin-1 characters with an arbitrary substitute
ASCII character and avoid this rendering mishap leading to
syntax tests failures. However, it has been overlooked at
the time that metadata description (in shorthand) to follow
spurious U+FFFD characters may be *distinct* and make the
remainder of such a line, ASCII characters and whatnot, also
unequal between compared screendump files.
While it is straightforward to adapt current filter files to
ignore the line characters after the leftmost U+FFFD,
> It is challenging and error-prone to keep up to date filter
> files because moving around examples in source files will
> likely make redundant some previously required filter files
> and, at the same time, it may require creating new filter
> files for the same source file; substituting one multibyte
> character for another multibyte character will also demand
> a coordinated change for filter files.
Besides, unconditionally dropping arbitrary parts of a line
is rather too blunt an instrument. An alternative approach
is to not use the supported filtering for this purpose; let
a syntax test pass or fail initially; then *if* the same
failure is imminent, drop the leftmost U+FFFD and the rest
of the previously seen line (repeating it for all previously
seen unequal lines) before another round of file contents
comparing. The obvious disadvantage with this filtering,
unconditional and otherwise, is that if there are consistent
failures for _other reasons_ and the unequal parts happen to
be after U+FFFDs, then spurious test passing can happen when
stars align for _a particular test runner_.
Hence syntax test authors should strive to write as little
significant text after multibyte characters as syntactically
permissible, write multibyte characters closer to EOL in
general, and make sure that their checked-in and published
"*.dump" files do not have any U+FFFDs.
It is also practical to refrain from attempting screendump
generation if U+FFFDs can already be discovered, and instead
try re-running from scratch the syntax test in hand, while
accepting other recently generated screendumps without going
through with new rounds of verification.
Reference:
https://github.com/vim/vim/pull/16470#issuecomment-2599848525closes: #17704
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
These file filters are not sufficient to work around #16559
and are to be superseded by a more promising alternative.
related: #17704
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Improve formatting and naming consistency of the syntax tests.
closes: #17850
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match Ex command modifiers and functions with the same name correctly.
E.g., :browse and browse().
- Match full :eval command.
closes: #17789
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Don't match lower-case function names as errors when the qualifier
includes a dict/list accessor.
This is a less than perfect fix until qualified function call matching
is reworked.
fixes: #17766closes: #17780
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Highlight bytes literals
- Do not highlight Unicode escape sequences in bytes literals
fixes: #14033fixes: #17726closes: #17728
Signed-off-by: Rob B <github@0x7e.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Take over as file maintainer.
- Improve highlighting of legacy script examples by using :syn-iskeyword
with the default 'iskeyword' value. Vim9 script examples are not
supported yet.
- Match admonition labels in more contexts.
- Match URLs in more contexts.
fixes#17721closes: #17731
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match the range prefix separately as a count.
- Match an explicit count of 1, rarely used but seen in the wild.
- Allow whitespace between the count and command.
closes: #17717
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match more function calls.
- Contain function call syntax groups.
- Improve differentiation between Ex commands and builtin functions with
the same name. Remove special cases. Command modifiers are not
currently well differentiated from functions.
closes: #17712
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: tests: testdir is a bit messy
Solution: move test scripts into testdir/util/ directory
src/testdir/ has become a dumping ground mixing test cases with utility
functions. Let's fix this by moving all utility functions into the
testdir/util/ directory
Also a few related changes had to be done:
- Update Filelist
- update README.txt and mention the new directory layout
- fix shadowbuild by linking the util directory into the shadow dir
closes: #17677
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match escape sequences in :command replacement blocks.
- Match :substitute after escape sequences (a temporary fix until Ex
commands are contained).
fixes: #17326closes: #17663
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match Conceal, ComplMatchIns, MsgArea, Terminal, and User[1-9]
highlight groups.
- Generate the vimGroup syntax group from runtime/syncolor.vim.
- Match :SynColor and :SynLink as special user commands.
fixes#17467closes: #17556
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Generate Ex command modifiers from the modifier table in src/ex_docmd.c
closes: #17564
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The unamed register may be referenced as both @" and @@.
Remove the unused vimPlainRegister syntax group.
fixes: #17603.
closes: #17605
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Don't match the OR operator in expressions as a trailing bar.
closes: #17533
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Remove unmatchable :normal {mark,register} matches. The arg to :normal
is now handled separately and contained marks and registers are no
longer matched.
closes: #17571
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
There is no pattern after the user event name. The user event name is
the pattern.
closes: #17568
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Fix highlighting of function names including /fu\%[nction]/ (E.g.,
s:func(), foo.fu(), fu.func())
- Match :delfunction argument.
Reported by Aliaksei Budavei.
closes: #17428
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Limit heredoc matches to assignment statements. Matching these at the
top level is very slow.
closes: #17473
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The opening curly brace must be followed by whitespace, comment or
trailing bar.
closes: #17454
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>