* Add buffer information to tabline_update
Most terminal implementations of the tabline display buffer and tab
information. Many neovim-qt users disable GuiTabline because it lacks
functionality provided in the terminal implementation.
The tabline_update event should include buffer information too, so client GUIs
can display rich useful tabs.
Upstream tree-sitter raised the number of pending matches for a query cursor
from 32 to 64k in <https://github.com/tree-sitter/tree-sitter/commit/
78010722a49ed6224c773c22b0d25a8c9fbde584>, which severely impacted performance
for some highlighting queries. This uses the `ts_query_cursor_set_match_limit`
function introduced in <https://github.com/tree-sitter/tree-sitter/commit/
cd96552448a6e0d4eb27fc54b27cb5130c4b6f76> to manually set this back to the old
default of 32.
Fixes#14897
Problem: Formatting using quickfixtextfunc is lost when updating location
lists for different buffers. (Yorick Peterse)
Solution: Use the right window for the locaiton list. (Yegappan Lakshmanan,
closesvim/vim#8400, closesvim/vim#8403)
ad52f96a2d
The `onexit` handler could set `message_callbacks` to `nil` within the
luv event loop while the mainloop runs a function that tries to access
`message_callbacks`.
This adds some checks to prevent errors in that case.
Fixes https://github.com/neovim/neovim/issues/14863
Problem: No error when using alpha delimiter with :global.
Solution: Check the delimiter like with :substitute. (closesvim/vim#8415)
419a40ac96
N/A patches for version.c:
vim-patch:8.1.2391: cannot build when __QNXNTO__ is defined
Problem: Cannot build when __QNXNTO__ is defined. (Ian Wayne Larson)
Solution: Move the check for "qansi". (Ken Takata, closesvim/vim#5317)
c95e8d6490
vim-patch:8.2.2294: VMS: a few remaining problems
Problem: VMS: a few remaining problems.
Solution: Add VMS specific changes. Add Lua support. (Zoltan Arpadffy)
82c38fe508
vim-patch:8.2.3034: installing packages on github CI sometimes fails
Problem: Installing packages on github CI sometimes fails.
Solution: Update package information first. (Christian Brabandt,
closesvim/vim#8432)
ef7be8348f
vim-patch:8.2.3037: configure reports libcanberra when checking for libsodium
Problem: Configure reports libcanberra when checking for libsodium.
Solution: Adjust the message. (Ozaki Kiichi, closesvim/vim#8435)
8ce3ca8961
vim-patch:8.2.3038: Amiga built-in version string doesn't include build date
Problem: Amiga built-in version string doesn't include build date.
Solution: Add the build date if available. (Ola Söder, closesvim/vim#8437)
cc65040986
vim-patch:8.2.3043: Amiga: cannot get the shell size on MorphOS and AROS
Problem: Amiga: cannot get the shell size on MorphOS and AROS.
Solution: Use control sequences. (Ola Söder, closesvim/vim#8438)
d415d26913
Problem: BufUnload is not triggered for the quickfix dummy buffer.
Solution: Do trigger BufUnload. (Pontus Leitzler,closes vim/vim#7518, closesvim/vim#7517)
Fix white space around "=".
1cfb9bb5c0
Problem: Code to handle callbacks is duplicated.
Solution: Add callback_T and functions to deal with it.
3a97bb3f0f
Port Vim's put_callback() as callback_put()
because Neovim's naming convention is {type}_{action},
not {action}_{type}.
Renaming put_callback type as PutCallback.
https://neovim.io/develop/style-guide.xml#Type_Names
As per #14236, performing extmark cleanup in a certain namespace does
not guarantee removing all the extmarks inside given namespace.
The issue resides within the tree node removal method and results in
a couple of rare edge cases.
To demonstrate what causes this bug, I'll give an example covering one
of the edge cases.
=== AN EXAMPLE ===
(A) (B) (C) (D) (E)
--------- --------- --------- --------- ---------
<0, 1> <0, 1> <0, 1> <0, 1> <0, 1>
<0, 2> <0, 2> <0, 2> <0, 2> <0, 2>
<0, 3> <0, 3> <0, 3> <0, 3> <0, 3>
<0, 4> <0, 4> <0, 4> <0, 4> <0, 4>
<0, 5> <0, 5> <0, 5> <0, 5> <0, 5>
<0, 6> <0, 6> <0, 6> <0, 6> <0, 6>
<0, 7> <0, 7> <0, 7> <0, 7> <0, 7>
<0, 8> <0, 8> <0, 8> <0, 8> <0, 8>
<0, 9> <0, 9> * * <0, 9> * <0, 9>
[0, 10] * [0, 10] <0, 9> [0, 11] [0, 11]
[0, 11] [0, 11] [0, 11] [0, 12] [0, 12] *
[0, 12] [0, 12] [0, 12] [0, 13] [0, 13]
[0, 13] [0, 13] [0, 13] [0, 14] [0, 14]
[0, 14] [0, 14] [0, 14] [0, 15] [0, 15]
[0, 15] [0, 15] [0, 15] [0, 16] [0, 16]
[0, 16] [0, 16] [0, 16] [0, 17] [0, 17]
[0, 17] [0, 17] [0, 17] [0, 18] [0, 18]
[0, 18] [0, 18] [0, 18] [0, 19] [0, 19]
[0, 19] [0, 19] [0, 19] [0, 20] [0, 20]
[0, 20] [0, 20] [0, 20]
DIAGRAM EXPLANATION
* Every column is a state of the marktree at a certain stage.
* To make it simple, I don't draw the whole tree. What you see are
2 leftmost parent nodes ([0, 10], [0, 20]) and their children placed
in order `MarkTreeIter` would iterate through. From top to bottom.
* Numbers on this diagram represent extmark coordinates. Relative
positioning and actual mark IDs used by the marktree are avoided
for simplicity.
* 2 types of brackets around coordinates represent 2 different
extmark namespaces (`ns_id`s).
* '*' shows iterator position.
ACTUAL EXPLANATION
Let's assume, we have two sets of extmarks from 2 different plugins:
* Plugin1: <0, 1-9>
* Plugin2: [0, 10-20]
1. Plugin2 calls
`vim.api.nvim_buf_clear_namespace(buf_handle, ns_id, 0, -1)`
to clear all its extmarks which results in `extmark_clear` call.
2. The iteration process goes on ignoring extmarks with irrelevant
`ns_id` from Plugin1, until it reaches [0, 10], entering state (A).
3. At the end of cleaning up process, `marktree_del_itr` gets called.
This function is supposed to remove given node and, if necessary,
restructure the tree. Also, move the iterator to the next node.
The bug occurs in this function.
4. The iterator goes backwards to the node's last child, to put it
in the place of its deleted parent later. (B)
5. The parent node is deleted and replaced with its child node. (C)
6. Since now this node has 8 children, which is less than
`MT_BRANCH_FACTOR - 1`, it get's merged with the next node. (D)
7. Finally, since at (B) the iterator went backward, it goes forward
twice, skipping [0, 11] node, causing this extmark to persist,
causing the bug. (E)
ANALYSIS AND SOLUTION
The algorithm works perfectly when the parent node gets replaced by
its child, but no merging occurs. I.e. the exact same diagram,
but without the (D) stage. If not for (D), it would iterate to <0, 9>
and then to [0, 11]. So, iterating twice makes sense. The actual problem
is in (C) stage, because the iterator index isn't adjusted and still
pointing to no longer existent node. So my solution is to adjust
iterator index after removing the child node.
More info: https://github.com/neovim/neovim/pull/14719
It's happening because do_source is only expected to return FAIL when it
was unable to open file . But `nlua_exec_file` returns fail for parsing
and execution error too . Those errors are emitted through `nlua_error`.
So now return value of nlua_exec_file is ignored like do_cmdline. It now
only returns fail when it was unable to open file that check is done
before calling nlua_exec_file or do_cmdline. Errors in nlua_exec_file
are still directly emitted through nlua_error like before.
When a keymap is set from lua currently verbose message says
it's set from line 1. That's incorrect because we don't really know when
it was set. So until proper :verbose support isn't added for sourceing
lua it shouldn't say where it was set at.