Order the keywords by expected frequency: "def" and "class" are assumed
to be more likely than "async def" in the majority of Python code.
closes: vim/vim#180322f7e4eb335
Co-authored-by: Jon Parise <jon@indelible.org>
Problem: filetype: Cangjie files are not recognized
Solution: Detect *.cj files as cangjie filetype, include a syntax plugin
(WuJunkai2004)
This commit introduces a new syntax highlighting file for the Cangjie
programming language, includes 4 parts as required:
- The main syntax file: runtime/syntax/cangjie.vim
- The filetype detection rule in: runtime/filetype.vim
- The documentation update in: runtime/doc/syntax.txt
- Some menus
References:
- https://gitcode.com/Cangjie
- https://cangjie-lang.cn/
fixes: 18014
closes: vim/vim#180270c4405a6b2
Co-authored-by: WuJunkai2004 <wujunkai20041123@outlook.com>
Problem: many FileType autocommands assume curbuf is the same as the target
buffer; this can cause &syntax to be restored for the wrong buffer in some cases
when TSHighlighter:destroy is called.
Solution: run nvim_exec_autocmds in the context of the target buffer via
nvim_buf_call.
This is matters for cross-compiling where we might not
be able to run the "nvim" binary on the host.
Instead reimplement the helptags extractor as a small
lua script, which we can run on the host using the nlua0
helper already used for other generator scripts.
Problem: attrs allocation and fuzzy growarray could leak on early
returns
Solution: Ensure proper cleanup of allocated memory on exit paths
(glepnir)
closes: vim/vim#18038c7c10f8c11
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: fuzzy.c can be further improved
Solution: Fix memory leak and refactor it (glepnir).
Optimize performance and memory allocation:
- Fix memory leak in fuzzy_match_in_list.
- using single memory allocation in match_positions
- Improve has_match performance and add null pointer checks
closes: vim/vim#1801259799f3afa
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: on_detach may be called after buf_freeall and other important things,
plus its textlock restrictions are insufficient. This can cause issues such as
leaks, internal errors and crashes.
Solution: disable buffer updates in buf_freeall, before autocommands (like the
order after #35355 and when do_ecmd reloads a buffer). Don't do so in
free_buffer_stuff; it's not safe to run user code there, and buf_freeall already
runs before then; just free them to avoid leaks if buf_freeall autocommands
registered more for some reason.
Fixes#28084Fixes#33967Fixes#35116
Problem:
Buffer-updates on_detach callback is invoked before buf_freeall(), which
deletes autocmds of the buffer (via apply_autocmds(EVENT_BUFWIPEOUT,
...)). Due to this, buffer-local autocmds executed in on_detach (e.g.,
LspDetach) are not actually invoked.
Solution:
Call buf_updates_unload() before buf_freeall().
Problem: Unicode has deprecated some code-points
Solution: Update the digraph tables to align with the Unicode v16
release (David Friant)
This commit updates the digraphs Left-Pointing Angle Bracket '</'
and Right-Pointing Angle Bracket '/>' to account for the fact that
the old Unicode codepoints for them (2329 and 232A, respectively)
have been deprecated. As per the Miscellaneous Technical code chart
(https://www.unicode.org/charts/PDF/U2300.pdf), the old digraphs
have been reassigned to the CJK Left Angle Bracket and Right Angle
Bracket (3008 and 3009) with their declaration moved to the
appropriate block.
This commit also introduces the new digraphs '<[' and ']>' to
represent the Mathematical Left Angle Bracket and Mathematical
Right Angle Bracket (27E8 and 27E9) to replace the deprecated code
points in the Technical block.
Tests have been added and, I believe, the documentation has been
updated accordingly.
closes: vim/vim#17990c08b94b072
Co-authored-by: David Friant <friant@HPEnvyx360.friant.dev>
Problem:
Detection of the pynvim module is currently done by finding the first
Python interpreter in the `PATH` and checking if it can import pynvim.
This has several problems:
- Activation of an unrelated Python virtual environment will break
automatic detection, unless pynvim is also installed in that
environment.
- Installing pynvim to the expected location is difficult. User
installation into the system-wide or user-wide Python site area is now
deprecated. On Ubuntu 24.04 with Python 3.12, for example, the
command `pip install --user pynvim` now fails with the error message
`error: externally-managed-environment`.
- Users may create a dedicated virtual environment in which to install
pynvim, but Nvim won't detect it; instead, they must either activate
it before launching Nvim (which interferes with the user of other
virtual environments) or else hard-code the variable
`g:python3_host_prog` in their `init.vim` to the path of the correct
Python interpreter. Neither option is desirable.
Solution:
Expose pynvim's Python interpreter on the `PATH` under the
name `pynvim-python`. Typical user-flow:
1. User installs either uv or pipx.
2. User installs pynvim via:
```
uv tool install --upgrade pynvim
# Or:
pipx install --upgrade pynvim
```
With corresponding changes in pynvim https://github.com/neovim/pynvim/issues/593
the above user-flow is all that's needed for Nvim to detect the
installed location of pynvim, even if an unrelated Python virtual
environments is activated. It uses standard Python tooling to automate
the necessary creation of a Python virtual environment for pyenv and the
publication of `pynvim-python` to a directory on `PATH`.
Problem:
Additional include directories in DEPS_INCLUDE_FLAGS variable are not
quoted. Paths with spaces break the resulting compile command.
Solution:
Enclose values in double quotes.
Note: normally we should avoid manual quoting, but in this case we can't
because of how `DEPS_INCLUDE_FLAGS` is used in `BuildLuv.cmake`
and `BuildLpeg.cmake`.
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: vim/vim#17403closes: vim/vim#179288f9de4991e
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: tests: fuzzy buffer name completion test doesn't match
successfully (after 9.1.1627).
Solution: Update pattern to account for the change in case sensitivity.
Also mark Test_search_stat_option() as flaky as it can still
sometimes fail (zeertzjq).
closes: vim/vim#17992891353671a
Some terminals support the CSI 8 t sequence to resize their own window
area. Neovim will emit this sequence when the TUI is resized
programatically, but it should not be emitted when the TUI is resized
because the host terminal was resized, as that results in an infinite
resize loop.
Don't print ABI version of duplicated parsers that are later in the
runtime path (see [#35326]).
Change the sorting from `name > path` to `name > rtpath_index`, this
ensures the first (loaded) parser is first in the list and any
subsequent parsers can be considered "not loaded".
This is fuzzy at best since `vim.treesitter.language.add` can take a
path to a parser and change the load order.
The correct solution is for `vim.treesitter.language.inspect` to return
the parser path so we can compare against it and/or for it to also be
able to take a path to a parser so we can inspect it without loading it
first.
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
These are special names by convention, and giving them distinct
highlighting is a nice visual clue (using Identifier by default).
This group is named "pythonClassVar" to match the name used by
python-syntax. Some third-party color schemes are aware of this
name and customized their colors accordingly.
closes: vim/vim#179681ee1d9b43d
Co-authored-by: Jon Parise <jon@indelible.org>
