**Problem:** Some weird languages have different comment syntax
depending on the location in the code, and we do not have a way to
determine the correct `commentstring` for these special cases.
**Solution:** Allow queries to specify `commentstring` values in
metadata, allowing users/`nvim-treesitter` to provide a better
commenting experience without hugely increasing the scope of the code in
core.
Problem: preinsert requires bot "menu" and "menuone" to be set,
but "menu" is redundant (after v9.1.1160)
Solution: preinsert only requires menuone (glepnir)
closes: vim/vim#1676394a045ed56
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: The 'preinsert' feature requires Ctrl-Y to confirm insertion,
but Ctrl-Y only works when the popup menu (pum) is displayed.
Without enforcing this dependency, it could lead to confusing
behavior or non-functional features.
Solution: Modify ins_compl_has_preinsert() to check for both 'menu' and
'menuone' flags when 'preinsert' is set. Update documentation
to clarify this requirement. This avoids adding complex
conditional behaviors. (glepnir)
fixes: vim/vim#16728closes: vim/vim#16753a2c5559f29
Co-authored-by: glepnir <glephunter@gmail.com>
Problem:
- The doc says the default `g:lua_subversion` is 2, but in fact it is 3
(see `runtime/syntax/lua.vim`)
- `includeexpr` doesn't work with module in `init.lua`
Solution:
- Update documentation
- Assign value to option `&include`
- Add function `LuaInclude` and assign it to `l:&includeexpr`
closes: vim/vim#1665500a00f5d3f
Co-authored-by: brianhuster <phambinhanctb2004@gmail.com>
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: No way to check the version of a treesitter parser.
Solution: Add version metadata (ABI 15 parsers only) as well as parser state count and supertype information (ABI 15) in `vim.treesitter.language.inspect()`. Also graduate the `abi_version` field, as this is now the official upstream name.
---------
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Problem: Sourcing buffer lines may lead to errors for conflicts.
Solution: Add the ++clear argument. (Yegappan Lakshmanan, closesvim/vim#9991)
35dc17634d
Documentation changes only. Vim9script is N/A.
Cherry-pick another documentation change for :source from latest Vim.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Sourcing buffer lines is too complicated.
Solution: Simplify the code. Make it possible to source Vim9 script lines.
(Yegappan Lakshmanan, closesvim/vim#9974)
85b43c6cb7
This commit changes the behavior of sourcing buffer lines to always have
a script ID, although sourcing the same buffer always produces the same
script ID.
vim-patch:9.1.0372: Calling CLEAR_FIELD() on the same struct twice
Problem: Calling CLEAR_FIELD() on the same struct twice.
Solution: Remove the second CLEAR_FIELD(). Move the assignment of
cookie.sourceing_lnum (zeertzjq).
closes: vim/vim#14627f68517c167
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Need to write script to a file to be able to source them.
Solution: Make ":source" use lines from the current buffer. (Yegappan
Lakshmanan et al., closesvim/vim#9967)
36a5b6867b
Most code and test changes are reverted or modified again in patch
8.2.4603, so only port parts that are untouched in patch 8.2.4603.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem:
Descriptions are somewhat vague. nvim_set_current_line modifies contents
but nvim_set_current_buf does not, etc.
Solution:
- Make it clear that these functions accept or return a winid/tabid by
linking to that concept in help.
- Only these few files use the term "handles", so replace them with the
more conventional terminology.
- Add a new help section for tab-ID. This concept is unique to neovim
because vim exposes tabnr, but not tab handles. This section is
modelled after `:h winid`.
Problem:
Indenting text is a common task in plugins/scripts for
presentation/formatting, yet vim has no way of doing it (especially
"dedent", and especially non-buffer text).
Solution:
Introduce `vim.text.indent()`. It sets the *exact* indentation because
that's a more difficult (and thus more useful) task than merely
"increasing the current indent" (which is somewhat easy with a `gsub()`
one-liner).
TSHighlighter now places marks for conceal_lines metadata. A new
internal decor provider callback _on_conceal_line was added that
instructs the highlighter to place conceal_lines marks whenever the
editor needs to know whether a line is concealed. The bundled markdown
queries use conceal_lines metadata to conceal code block fence lines.
Problem: there is no way to distinguish between user's explicit
completion stop/cancel and other automated reasons.
Solution: update "cancel" reason to be set only on explicit CTRL-e, and
set intentionally vague "discard" otherwise.
Problem:
- Many other ftplugin have defined 'omnifunc', but the Lua one doesn't
define one, even though there is `vim.lua_omnifunc()`
- Users may want "stupid" completion to fix Lua config with
`nvim --clean` in case they breaks it
Solution:
Set 'omnifunc' to 'v:lua.vim.lua_omnifunc' in ftplugin/lua.lua
Problem: It's difficult to navigate large structured text files (vim
help, checkhealth, Markdown).
Solution: Support `gO` for table of contents and `]]`/`[[` for moving
between headings for all these filetypes using treesitter queries.
Refactor: colorization of highlight groups is moved to the `help` ftplugin
while headings-related functionality is implemented in a private
`vim.treesitter` module for possible future use for other filetypes.
**Problem:** Currently, parsing is asynchronous, but it involves a
(sometimes lengthy) step which finds all injection ranges for a tree by
iterating over that language's injection queries. This causes edits in
large files to be extremely slow, and also causes a long stutter during
the initial parse of a large file.
**Solution:** Break up the injection query iteration over multiple event
loop iterations.
The new native commenting functionality is currently not used when
editing mail. One could reasonably expect it to change the "quote" state
of any given line in the mail (i.e. the preceding ">"), which would be
very handy and feel natural when editing mail. Especially since the
current file already uses "setlocal comments+=n:>".
Solution: Add commentstring to `> %s` to be used in files of type mail.
closes: vim/vim#1666927f5136761
Co-authored-by: Lucas Eekhof <105216949+eekhof@users.noreply.github.com>
Problem: Messages preceding a `cmdline_show->prompt` event can not be
distinguished as such when receiving the event. (But since
`msg_show` handlers should be scheduled, one can already check
whether a prompt is active when displaying the message.)
Solution: Rather than add a new kind again, use the `confirm` kind.
Could be seen as slightly misleading where it is more of
a choice rather than a confirmation, but that already applies
to `confirm()` as well...
PuTTY sets TERM=xterm, but sends ESC[1~ and ESC[4~ for Home/End keys,
which does not match what the 'xterm' terminfo has for khome/kend, so
libtermkeys instead reports them as the original DEC VT220 names.
The VT220 came with a DEC LK201 keyboard which had the following keys in
the area above arrow keys (where PCs now have Ins/Del/Home/End/etc):
┌────────┬────────┬────────┐
│ Find │ Insert │ Re- │
│ │ Here │ move │
├────────┼────────┼────────┤
│ Select │ Prev │ Next │
│ │ Screen │ Screen │
└────────┴────────┴────────┘
These would send ESC[x~ sequences in the expected order:
┌────────┬────────┬────────┐
│ ESC[1~ │ ESC[2~ │ ESC[3~ │
├────────┼────────┼────────┤
│ ESC[4~ │ ESC[5~ │ ESC[6~ │
└────────┴────────┴────────┘
Modern terminals continue to use the same sequences for Ins/Del as well
as PageUp/PageDn. But the VT220 keyboard apparently had no Home/End, and
PuTTY apparently chose to re-purpose the Find/Select key sequences for
Home/End (even though it claims to emulate Xterm and this doesn't match
what actual Xterm does).
So when Home/End are used in Neovim through PuTTY with TERM=xterm (the
default setting), libtermkey finds no match for the received sequences
in the terminfo database and defaults to reporting them as <Find> and
<Select> respectively.
PuTTY is not unique here -- tmux *also* sends ESC[1~ and ESC[4~ after
its internal translation -- but the difference is that 'tmux' terminfo
correctly maps them to Home/End so Neovim recognizes them as such, while
PuTTY defaults to using 'xterm' which uses a different mapping.
This initial patch only allows Neovim to recognize <Find> and <Select>
key codes as themselves, so that the user could manually map them e.g.
using ":imap <Find> <Home>".
Alternatives:
- Using TERM=putty(-256color) would of course be the most correct
solution, but in practice it leads to other minor issues, e.g. the
need to have different PuTTY config profiles for older or non-Linux
systems that lack that terminfo, or tmux's insistence on rendering
italics as reverse.
- Using Neovim through tmux avoids the problem (as tmux recognizes
ESC[1~ on input), but is something that needs to be manually run
every time.
The keycodes.h constants are slightly misnamed because K_SELECT was
already taken for a different purpose.
Problem: `vim.treesitter._create_parser()` silently loads the buffer,
bypassing the swapfile prompt.
Solution: Error for an unloaded buffer, ensure buffer is loaded in
`vim.treesitter.start()` instead.
vim-patch:partial:9.1.1084: Unable to persistently ignore events in a window and its buffers
Problem: Unable to persistently ignore events in a window and its buffers.
Solution: Add 'eventignorewin' option to ignore events in a window and buffer
(Luuk van Baal)
Add the window-local 'eventignorewin' option that is analogous to
'eventignore', but applies to a certain window and its buffers. Identify
events that should be allowed in 'eventignorewin', adapt "auto_event"
and "event_tab" to encode this information. Window context is not passed
onto apply_autocmds_group(), and when to ignore an event is a bit
ambiguous when "buf" is not "curbuf", rather than a large refactor, only
ignore an event when all windows into "buf" are ignoring the event.
b7147f8236
vim-patch:9.1.1102: tests: Test_WinScrolled_Resized_eiw() uses wrong filename
Problem: tests: Test_WinScrolled_Resized_eiw() uses wrong filename
(Luuk van Baal, after v9.1.1084)
Solution: Rename the filename to something more unique
bfc7719e48
Problem:
No obvious way to see diagnostics without configuring it first.
Solution:
Add `Show Diagnostics`, `Show All Diagnostics` and `Configure
Diagnostics` buttons to the context menu.
Problem: has('bsd') is true for GNU/Hurd
Solution: exclude GNU/Hurd from BSD feature flag
(Zhaoming Luo)
GNU/Hurd, like Mac OS X, is a BSD-based system. It should exclude
has('bsd') feature just like what Mac OS X does. The __GNU__ pre-defined
macro indicates it's compiled for GNU/Hurd.
closes: vim/vim#16580a41dfcd55b
Co-authored-by: Zhaoming Luo <zhmingluo@163.com>
Now `:InspectTree` will show missing nodes as e.g. `(MISSING identifier)`
or `(MISSING ";")` rather than just `(identifier)` or `";"`. This is
doable because the `MISSING` keyword is now valid query syntax.
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Problem: vim_strnchr() is strange and unnecessary (after v9.1.1009)
Solution: Remove vim_strnchr() and use memchr() instead. Also remove a
comment referencing an #if that is no longer present.
vim_strnchr() is strange in several ways:
- It's named like vim_strchr(), but unlike vim_strchr() it doesn't
support finding a multibyte char.
- Its logic is similar to vim_strbyte(), but unlike vim_strbyte() it
uses char instead of char_u.
- It takes a pointer as its size argument, which isn't convenient for
all its callers.
- It allows embedded NULs, unlike other "strn*" functions which stop
when encountering a NUL byte.
In comparison, memchr() also allows embedded NULs, and it converts bytes
in the string to (unsigned char).
closes: vim/vim#1657934e1e8de91
Problem: SpotBugs compiler can be improved
Solution: runtime(compiler): Improve defaults and error handling for
SpotBugs; update test_compiler.vim (Aliaksei Budavei)
runtime(compiler): Improve defaults and error handling for SpotBugs
* Keep "spotbugs#DefaultPreCompilerTestAction()" defined but
do not assign its Funcref to the "PreCompilerTestAction"
key of "g:spotbugs_properties": there are no default and
there can only be introduced arbitrary "*sourceDirPath"
entries; therefore, this assignment is confusing at best,
given that the function's implementation delegates to
whatever "PreCompilerAction" is.
* Allow for the possibility of relative source pathnames
passed as arguments to Vim for the Javac default actions,
and the necessity to have them properly reconciled when
the current working directory is changed.
* Do not expect users to remember or know that new source
files ‘must be’ ":argadd"'d to be then known to the Javac
default actions; so collect the names of Java-file buffers
and Java-file Vim arguments; and let users providing the
"@sources" file-lists in the "g:javac_makeprg_params"
variable update these file-lists themselves.
* Strive to not leave behind a fire-once Syntax ":autocmd"
for a Java buffer whenever an arbitrary pre-compile action
errors out.
* Only attempt to run a post-compiler action in the absence
of failures for a pre-compiler action. Note that warnings
and failures are treated alike (?!) by the Javac compiler,
so when previews are tried out with "--enable-preview",
remember about passing "-Xlint:-preview" too to also let
SpotBugs have a go.
* Properly group conditional operators when testing for key
entries in a user-defined variable.
* Also test whether "javaExternal" is defined when choosing
an implementation for source-file parsing.
* Two commands are provided to toggle actions for buffer-local
autocommands:
- SpotBugsRemoveBufferAutocmd;
- SpotBugsDefineBufferAutocmd.
For example, try this from "~/.vim/after/ftplugin/java.vim":
------------------------------------------------------------
if exists(':SpotBugsDefineBufferAutocmd') == 2
SpotBugsDefineBufferAutocmd BufWritePost SigUSR1
endif
------------------------------------------------------------
And ":doautocmd java_spotbugs User" can be manually used at will.
closes: vim/vim#16140368ef5a48c
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
