Problem:
Previously, the fallback logic to ".conf" was located outside of
`vim.filetype.match()` and directly within the AutoCmd definition. As a
result, `vim.filetype.match()` would return nil instead of ".conf" for
fallback cases (#30100).
Solution:
Added a boolean return value to `vim.filetype.match()` that indicates
whether the match was the result of fallback. If true, the filetype will
be set using `setf FALLBACK <ft>` instead of `setf <ft>`.
Problem:
fe4faaf81a added an invalid "redirect" item, which caused the
assert() to fail, which then caused the neovim/doc/ CI to fail:
https://github.com/neovim/doc/actions/runs/18830779387/job/53721736276 :
The previous commit e69beb9b1a tried to fix a different issue, which
has gone hidden because the "invalid tags" failure has been present on
the neovim/doc/ but was silently failing.
invalid tags: {
["g:netrw_keepdir"] = "usr_22.txt",
netrw = "vi_diff.txt",
...
plugins = "editorconfig"
}
Solution:
- Fix the invalid redirect.
- Improve the redirects assertion.
1. Every hyperlink-like element was replaced by `"$1"` (where $1 is the original string showed in the hyperlink);
2. Arrows `--->` were used in lines containing practice examples when no editing text is involved;
3. Context on interactivity was minimally adapted when strictly needed, not to disrupt the original tutor's intent;
4. Tests regarding the tutor file refactored to ensure the new syntax is not flagged as an error.
Problem: Setting a filetype before configuring default options for ui2
buffers (pager, cmd, ...) prevents users from setting their own options.
Solution: Call nvim_set_option_value after defaults are set.
Closes#36314
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem:
Error extracting content-length causes all future coroutine resumes to
fail.
Solution:
Replace coroutine.wrap with coroutine.create in create_read_loop
so that we can check its status and catch any errors, allowing us to
stop the lsp client and avoid repeatedly resuming the dead coroutine.
- Highlight :@ as a normal Ex command rather than something special.
- Fix erroneous matching of the Ex command as a register variable.
closes: vim/vim#18624842c7788a5
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
- Use the optional tail command-name spec at :help :syntime.
- Match full :syntime command and highlight args.
7dba04f15c
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: username parsing bug in netrw plugin when using remote adding
feature
Solution: Allow any characters except for "@" (Václav Kobera), add a
test for the netrw plugin
closes: vim/vim#18611f17f78c557
Co-authored-by: Václav Kobera <vasekobera@gmail.com>
Problem: pre-inserted text not exposed in complete_info()
Solution: Add the pre-inserted text to the complete_info() Vim script
function (Girish Palya)
closes: vim/vim#18571
Feat: expose preinserted text in complete_info()
ef5bf58d8c
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: Cmdline history not updated when mapping both <Up> and <CR>.
Solution: Consider the command typed when in Cmdline mode and there is
no pending input (zeertzjq).
Although the existing behavior technically does match documentation, the
"completely come from mappings" part is a bit ambiguous, because one may
argue that the command doesn't completely come from mappings as long as
the user has typed a key in Cmdline mode. I'm not entirely sure if this
change will cause problems, but it seems unlikely.
fixes: vim/vim#2771
related: neovim/neovim#36256closes: vim/vim#1860797b6e8b424
This fixes a bug introduced in 2a33b499a3d7f46dc307234847a6562cef6cf1d8:
When makeTargetinDefine ends with makeIdent, makeSpecTarget or
makeComment, the following line is also matched as makeTargetinDefine.
So, add keepend to prevent that just as makeTarget does.
related: vim/vim#18403closes: vim/vim#185707193cab6c8
Co-authored-by: Yiyang Wu <xgreenlandforwyy@gmail.com>
Problem:
Spell file downloads relied on Vimscript and netrw (:Nread). If netrw is
disabled, downloads fail.
Solution:
Port the logic to Lua as `nvim.spellfile` and wire it via a Lua plugin that
handles `SpellFileMissing`. Use `vim.net.request()` with a timeout for HTTP,
prompt via `vim.fn.input` and report via `vim.notify`.
Closes#7189
Problem:
Some LSP method handlers were making requests without specifying a
bufnr, defaulting to 0 (current). This works in most cases but
fails when client attaches to background buffers, causing
assertions in handlers to fail.
Solution:
Ensure bufnr is passed to Client.request for buffer-local methods.
**Problem:**
`vim.filetype.match({ filename = 'a.sh' })` returns `nil` because
an invalid buffer ID is passed to `vim.api.nvim_buf_get_lines()`.
For filetypes like `csh`, `txt`, or any other extensions that call
`_getlines()` or `_getline()` to detect their filetypes, the same
issue occurs.
When only the `filename` argument is passed, an error is raised
inside a `pcall()` that wraps the filetype detection function,
causing it to return no value without showing any error message.
**Solution:**
Validate the `bufnr` value in `_getlines()` and `_getline()`.
Problem: `PackChanged[Pre]` events with `kind=update` are triggered both
during plugin's initial installation and after already installed
plugin was updated.
It was a deliberate decision to allow writing only a single update
hook to act as a dedicated "build" entry point (like execute `make` or
`cargo build —release`). This mimics how other plugin managers have a
single "build" command.
This was a result of 'mini.deps' experience with the different
approach: "update" hooks are not run during install. This proved to be
confusing as it requires to write two hooks. But also the reason might
be that 'mini.deps' names it "checkout" hook instead of "update".
However, the `vim.pack` event approach makes it lower cost to handle
separate "update" and "install" events. Something like
`if ev.data.kind == 'install' or ev.data.kind == 'update' then`
instead of two autocommands.
Plus this makes clearer separation of events.
Solution: do not trigger `PackChanged[Pre] kind=update` event during
install.
Problem: Inside `PackChanged[Pre]` callbacks it might be useful to tell
if the affected plugin is active or not. It is already possible via
extra `vim.pack.get({ 'plug-name' })[1].active`, but it is not quite
user-friendly for something that might be needed frequently in real
world use cases.
Solution: Supply extra `active` event data field.
