A file containing only async functions (`async def func()`) wouldn't
previously match the pythonSync pattern.
Also, this pattern only matches at the beginning of the line, so it
won't ever match method definitions (which are indented within class
scopes). Update the comment accordingly.
closes: #17963
Signed-off-by: Jon Parise <jon@indelible.org>
Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org>
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>
Class and function definitions previously shared a single highlight
group (pythonFunction). This change gives classes their own highlight
group (pythonClass) that's linked to Structure.
closes: #17856
Signed-off-by: Jon Parise <jon@indelible.org>
Signed-off-by: Zvezdan Petkovic <zpetkovic@acm.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Buffer menu does not handle unicode names correctly
(after v9.1.1622)
Solution: Fix the BMHash() function (Yee Cheng Chin)
The Buffers menu uses a BMHash() function to generate a sortable number
to be used for the menu index. It used a naive (and incorrect) way of
encoding multiple ASCII values into a single integer, but assumes each
character to be only in the ASCII 32-96 range. This means if we use
non-ASCII file names (e.g. Unicode values like CJK or emojis) we get
integer underflow and overflow, causing the menu index to wrap around.
Vim's GUI implementations internally use a signed 32-bit integer for the
`gui_mch_add_menu_item()` function and so we need to make sure the menu
index is in the (0, 2^31-1) range.
To do this, if the file name starts with a non-ASCII value, we just use
the first character's value and set the high bit so it sorts after the
other ASCII ones. Otherwise, we just take the first 5 characters, and
use 5 bit for each character to encode a 30-bit number that can be
sorted.
This means Unicode file names won't be sorted beyond the first
character. This is likely going to be fine as there are lots of ways to
query buffers.
related: #17403closes: #17928
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Patch v9.1.1432 causes performance regressions
Solution: Revert "patch 9.1.1432: GTK GUI: Buffer menu does not handle
unicode correctly" (Yee Cheng Chin).
This reverts commit 08896dd330c6dc8324618fde482db968e6f71088.
The previous change to support Unicode characters properly in the
buffers menu resorted to removing all buffer menus and re-add the
buffers after doing a sort, per each buffer addition. This was quite
slow because if Vim is trying to load in multiple buffers at once (e.g.
when loading a session) this scales in O(n^2) and Vim can freeze for
dozens of seconds when adding a few hundred buffers.
related: #17405
related: #17928fixes: #17897
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: composer.lock and symfony.lock files not recognized
Solution: Detect composer.lock and symfony.lock files as json filetype
(Dietrich Moerman)
closes: #17945
Signed-off-by: Dietrich Moerman <dietrich.moerman@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Reformat parts to fit into 80 column window.
- Fix example with mandatory call with a range.
https://github.com/vim/vim/discussions/17950#discussioncomment-14055687
- Remove some duplicate information
closes: #17949
Signed-off-by: veotos <veotos@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: diff format erroneously detected
(Tomáš Janoušek)
Solution: Make the regex to detect normal diff format a bit stricter,
while at it, fix wrong test content from patch v9.1.1606
fixes: #17946
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match &option, and &[lg]:option variables.
- Match Ex commands after :bar.
- Fix matching of pre and post context text.
- Style - use '..' for string concatenation.
fixes#17567closes: #17653
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This brings the upstream files to commit 9dc3bd3 (ftplugin: escape Vim
special characters when opening docs, 2025-08-09). Note that not all
upstream files are included.
closes: #17956
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: a few more files are not recognized
Solution: guess Mail, Info and Terminfo files by its content
(lacygoill)
closes: #17880
Signed-off-by: lacygoill <lacygoill@lacygoill.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: When the parameter debug=msg is set and the command :option is
entered, error E94 will be displayed.
Solution: Add a check for the existence of the buffer before getting the
buffer number “option-window”.
Reproduce:
vim --clean -c "set debug=msg" -c "option"
Error detected while processing command line..script D:\Programs\Vim\vim91\optwin.vim:
line 9: E94: No matching buffer for option-window
closes: #17927
Signed-off-by: RestorerZ <restorer@mail2k.ru>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim's help file doesn't have any syntax for comments, but
'comments' and 'commentstring' are still set in the help
buffer.
Solution: Unset 'comments' and 'cms' in help buffer
closes: #17889
Signed-off-by: Phạm Bình An <111893501+brianhuster@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Correct expression syntax to match case in if and if-else clauses.
related: #8535closes: #17901
Signed-off-by: veotos <veotos@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: diff: using diff anchors with hidden buffers fails silently
Solution: Give specific error message for diff anchors when using hidden
buffers (Yee Cheng Chin).
Diff anchors currently will fail to parse if a buffer used for diff'ing
is hidden. Previously it would just fail as the code assumes it would
not happen normally, but this is actually possible to do if `closeoff`
and `hideoff` are not set in diffopt. Git's default diff tool "vimdiff3"
also takes advantage of this.
This fix this properly would require the `{address}` parser to be
smarter about whether a particular address relies on window position or
not (e.g. the `'.` address requires an active window, but `'a` or `1234`
do not). Since hidden diff buffers seem relatively niche, just provide a
better error message / documentation for now. This could be improved
later if there's a demand for it.
related: #17615closes: #17904
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
g:vimsyn_folding and g:vimsyn_embed regexps need to match case.
closes: #17914
Signed-off-by: veotos <veotos@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The '?' needs to be escaped, because the autocommand is using
file-patterns (glob like) and not a regex). See :h file-pattern
closes: #17890
Signed-off-by: Girish Palya <girishji@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
this was erroneously changed in commit
85cd509885a05c3a6bb029fb378b1295f107f8f6
related: #17857
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
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>
