vim-patch:8.1.1555: NOT_IN_POPUP_WINDOW is confusing
vim-patch:8.1.1586: error number used in two places
vim-patch:8.1.1599: compiler warning for uninitialized variable
vim-patch:8.1.1603: crash when using unknown highlighting in text property
vim-patch:8.1.1655: popup window border drawn wrong with multi-byte char
vim-patch:8.1.1675: listener list not correctly updated on listener_remove()
vim-patch:8.1.1710: Coverity found dead code
vim-patch:8.1.1844: buffer no longer unloaded when adding text properties
vim-patch:8.1.2071: when 'wincolor' is set text property changes highlighting
vim-patch:8.1.2211: listener callback "added" argument is not the total
vim-patch:8.1.2215: unreachable code in adjusting text prop columns
vim-patch:8.1.2216: text property in wrong place after :substitute
vim-patch:8.1.2298: missing part of 8.1.2296
vim-patch:8.1.2308: deleting text before zero-width textprop removes it
vim-patch:8.1.2369: cannot build with quickfix and without text properties
vim-patch:8.2.0124: compiler warnings for variable types
vim-patch:8.2.0126: textprop test fails
vim-patch:8.2.0967: unnecessary type casts for vim_strnsave()
vim-patch:8.2.1670: a couple of gcc compiler warnings
vim-patch:8.2.2429: :goto does not work correctly with text properties
vim-patch:8.2.2890: text property duplicated when data block splits
vim-patch:8.2.3062: internal error when adding several text properties
vim-patch:8.2.3372: line2byte() value wrong when adding a text property
vim-patch:8.2.3483: #ifdef for using sysinfo() is incomplete
vim-patch:8.2.4043: using int for second argument of ga_init2()
vim-patch:8.2.4144: cannot load libsodium dynamically
vim-patch:8.2.4960: text properties that cross lines not updated for deleted line
vim-patch:8.2.4961: build error with a certain combination of features
vim-patch:8.2.5014: byte offsets are wrong when using text properties
vim-patch:8.2.5041: cannot close a terminal popup with "NONE" job
vim-patch:9.0.0169: insufficient testing for line2byte() with text properties
vim-patch:9.0.0181: textprop test with line2byte() fails on MS-Windows
vim-patch:9.1.0633: Compilation warnings with `-Wunused-parameter`
vim-patch:9.1.0957: MS-Windows: conversion warnings
Problem: Wrong event order for nested cmdline in a conditional cmdline_block.
Solution: Emit all but the first cmdline_block event immediately after
getting the next command, before executing it.
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.
