As a matter of caution it sets it to the default gcc errorformat:
```
errorformat=%*[^"]"%f"%*\D%l: %m,"%f"%*\D%l: %m,%-Gg%\?make[%*\d]: *** [%f:%l:%m,%-Gg%\?make: *** [%f:%l:%m,%-G%f:%l: (Each undeclared identifier is reported only once,%-G%f:%l: for each function it appears in.),%-GIn file included from %f:%l:%c:,%-GIn file included from %f:%l:%c\,,%-GIn file included from %f:%l:%c,%-GIn file included from %f:%l,%-G%*[ ]from %f:%l:%c,%-G%*[ ]from %f:%l:,%-G%*[ ]from %f:%l\,,%-G%*[ ]from %f:%l,%f:%l:%c:%m,%f(%l):%m,%f:%l:%m,"%f"\, line %l%*\D%c%*[^ ] %m,%D%*\a[%*\d]: Entering directory %*[`']%f',%X%*\a[%*\d]: Leaving directory %*[`']%f',%D%*\a: Entering directory %*[`']%f',%X%*\a: Leaving directory %*[`']%f',%DMaking %*\a in %f,%f|%l| %m
```
so that the compiler keeps working after switching to others.
While likely only a subset is needed; such a subset has been proposed in
a commented errorformat;
checked to work for yamllint but ran out of steam for other compilers;
closes: vim/vim#1875474b4f9242e
Co-authored-by: Konfekt <Konfekt@users.noreply.github.com>
This formatting (although rare) is actually accepted by GHC, but vim
does not highlight it. This patch adds the simplest possible regex to
support the behavior.
Inconveniently, this might trigger weird formatting on lines that
contain errors, e.g. if the first backtick is removed from:
a `b` c `d` e
then `c` is going to be marked as an operator, which seems weird but is
valid.
closes: vim/vim#18776ddb88ab796
Co-authored-by: Mirek Kratochvil <exa.exa@gmail.com>
Problem: 'commentstring' requires the +folding feature but is used in
contexts other than folding.
Solution: Remove the +folding feature guards from 'commentstring' and
make it available in all builds (Doug Kearns).
closes: vim/vim#18731a08030c9f7
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: When assigning to @. in a :let command an incorrect "E15"
error is emitted.
Solution: Emit the correct "E354" error. (Doug Kearns).
An incorrect "E488" error was also emitted in Vim9 script assignments.
It appears that the code deleted in this commit was added to work around
a limitation in the returned value from find_name_end() that no longer
exists.
See commit 76b92b2830841fd4e05006cc3cad1d8f0bc8101b (tag: v7.0b).
closes: vim/vim#187572447131e00
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Wrong virtcol('$') with virtual text at EOL (rickhowe).
Solution: Also add 1 to end virtcol when there is virtual text.
(zeertzjq)
fixes: vim/vim#18761closes: vim/vim#18762d434f6c2a5
Problem: tests: not enough testing for wildtrigger() pum redrawing.
Solution: Also test redrawing when leaving cmdline mode (zeertzjq).
closes: vim/vim#18773eb33c2eb28
Problem:
If the buffer changes during iteration of the query matches,
`get_node_text()` may fail, showing an error to the user.
Solution:
Use `pcall` to not propogate the error to the user. Retry once if an
error occurred.
Problem:
Trying to match the search highlight groups to the Normal highlight for
the window can fail when the message highlighting contains a fg/bg that
the Normal highlight doesn't (like an error message in cmd will have
ErrorMsg highlight instead of MsgArea - which is Normal in cmd.)
Solution:
Link the search highlight groups to an empty group in 'winhighlight'
thus disabling them instead of overriding them with Normal/MsgArea/etc.
Limit the default truncation item to the current recursion range so
nested `nvim_eval_statusline()` calls don't reuse stale `stl_items`
pointers. Add a functional regression that evaluates a Lua statusline
helper which forces truncation to ensure the nested scenario stays
stable.
AI-Assist: OpenAI ChatGPT
Fixes#36616
Problem:
When running ":edit <url>", filetype detection is not triggered.
Solution:
Run the autocmds in the filetypedetect group after loading the content.
Problem:
After fetching remote content from a URL and adding it to the buffer,
the buffer is marked as modified. This is inconsistent with the original
netrw behavior, and it causes problems with `:e` to refresh or `:q` as
it prompts for saving the file even if the user hasn't touched the
content at all.
Solution:
Mark the buffer as unmodified right after adding the remote content to
the buffer.
Problem:
AUR does not want a web-scale implementation of "tee".
Solution:
- Only install "tee" on Windows.
- The build will still produce `./build/bin/tee` on all platforms, to
have more coverage and avoid special-cases in tests.
Technically the current behavior does match documentation. However, the
keys following <Cmd>/K_LUA aren't normally received by vim.on_key()
callbacks either, so it does makes sense to discard them along with the
preceding key.
One may also argue that vim.on_key() callbacks should instead receive
the following keys together with the <Cmd>/K_LUA, but doing that may
cause some performance problems, and even in that case the keys should
still be discarded together.
fix(ui2): hide search highlights in msg window.
Problem: Search highlighting is shown in the msg (and dialog) window.
Solution: Hide search highlighting in all but the pager window.
Problem:
Neovim no longer ships with a tee binary on Windows, which breaks
functionality for the :grep and :make commands.
nvim --clean
:grep foo or :make
"tee is not recognized as an internal or external command"
Solution:
Include a simple, no-dependency tee.c source file in the src/ directory.
Update CMakeLists.txt to build a tee executable alongside neovim during
the build process, and ensure the tee.exe program appears alongside the
neovim executable in the bin/ directory so that it is accessible for
:grep and :make.
tee.c was obtained from the vim codebase:
https://github.com/vim/vim/blob/master/src/tee/tee.c
And we modified it to fix performance issues.
Testing:
nvim --clean
:grep foo or :make, after setting a file to the makeprg option.
Verify that :grep results and error output from a compiler appear in the message pane.
ref https://github.com/neovim/neovim/issues/32431
fix https://github.com/neovim/neovim/issues/32504
Other tee options:
- [tee-win32](https://github.com/dEajL3kA/tee-win32): MIT. However,
I couldn't get it to build on my machine even after updating its
makefile to call my install of MSVC. It's also super optimized and
uses some processor intrinsics for multithreading.
- [gnu coreutils tee](https://gnuwin32.sourceforge.net/packages/coreutils.htm):
(Windows coreutils contains a tee.c. Last updated 2005. Did not build
immediately on my machine; we'd have to determine which definitions
from elsewhere in coreutils tee.c needs and incorporate them somehow.
- [WinTee](https://github.com/mpderbec/WinTee): Has no license. Last
updated 11 years ago. Relies on Visual Studio to build.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: running ./build/bin/nvim without make install
- doesn't respect local changes in ./runtime,
- includes the path where Nvim would be installed,
- ignores changes in precompiled Lua modules (like .../vim/_editor.lua)
Solution:
- use VIMRUNTIME=./runtime,
- use --luamod-dev
Problem:
With the typescript LSes typescript-language-server and vtsls,
omnicompletion on partial tokens for certain types, such as array
methods, and functions that are attached as attributes to other
functions, either results in no entries populated in the completion menu
(typescript-language-server), or an unfiltered completion menu with all
array methods included, even if they don't share the same prefix as the
partial token being completed (vtsls).
Solution:
Enable insertReplaceSupport and uses the insert portion of the lsp
completion response in adjust_start_col if it's included in the
response.
Completion results are still filtered client side.
Problem: the opts table also is param of util.open_floating_preview,
vim.diagnostic.Opts.Float missing some fields of open_floating_preview.
Solution: diagnostic.Opts.Float extend util.open_floating_preview.Opts
Fix#29267
Problem: No way to customize completion order across multiple servers.
Solution: Add `cmp` function to `vim.lsp.completion.enable()` options
for custom sorting logic.
Problem:
Starting Nvim on MinGW fails:
https://github.com/msys2/MINGW-packages/issues/25140
Unknown system error -1："C:\msys64\ucrt64\bin\nvim.exe"Failed to start Nvim server!
Solution:
On Windows, the main application manifest should use resource ID 1 (RT_MANIFEST).
Update `nvim.rc` to use `1 RT_MANIFEST nvim.manifest` instead of `2`,
ensuring the manifest is correctly embedded and recognized by the system.
ID = 1 is for executable files (.exe)
ID = 2 is for DLLs (/DLL)
From MSVC docs: "Use a value of 2 for a DLL to enable it to specify private dependencies."
https://learn.microsoft.com/en-us/cpp/build/reference/manifest-create-side-by-side-assembly-manifest
Problem: Cannot reuse same config with noautocmd for both window
creation and updates, even when value is unchanged.
Solution: Only reject noautocmd changes for existing windows.
Fixes compilation/link/installation on Cygwin with bundled dependencies
(cmake.deps). Only builds with LuaJIT are fixed. Linking against PUC LUA still
does not work.
Note: Luajit technically does not support Cygwin:
55a42da36e
Problem:
On macOS Tahoe, `make unittest` started failing with the following error.
````
test/unit/testutil.lua:784: test/unit/testutil.lua:768: (string) '
test/unit/testutil.lua:295: declaration specifier expected near 'ipc_info_object_type_t' at line 2297'
exit code: 256
stack traceback:
test/unit/testutil.lua:784: in function 'itp_parent'
test/unit/testutil.lua:822: in function <test/unit/testutil.lua:812>
````
Solution:
Update filter_complex_blocks.
This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.
While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
Problem:
scripts/check_urls.vim manually matches urls in the help pages and then
synchronously checks them via curl/wget/powershell. This is extremely
slow (~5 minutes for Nvims runtime on my machine) and prone to errors in
how the urls are matched.
Solution:
- Use Tree-sitter to find the urls in the help pages and `vim.net.request` to
check the responses.
- Add a `lintdocurls` build task and check it in CI (every Friday).
- Reopens a dedicated issue if it finds unreachable URLs.
- Drop the old check_urls.vim script.
**Problem:** Whenever `LanguageTree:parse()` is called, injection trees
from previously parsed ranges are dropped.
**Solution:** Allow the function to accept a list of ranges, so it can
return injection trees for all the given ranges.
Co-authored-by: Jaehwang Jung <tomtomjhj@gmail.com>
Remove codecs import and use open(..., encoding='utf-8', errors='replace', newline=None) in clint.py to avoid Python 3.14 DeprecationWarning; preserve existing CR handling.
Problem:
Users often jump and navigate through LSP windows to yank text.
Concealed markdown can make navigation through hyperlinks and code
blocks more difficult.
Solution:
Change 'concealcursor' from 'n' to '' to preserve clean display
while improving navigation and selection of the LSP response.
Closes#36537
Problem: Until now the UI callback called nvim__redraw() liberally.
It should only be needed when Nvim does not update the screen
in its own event loop.
Solution: Identify which UI events require immediate redrawing.
Problem: unnecessary and deprecated diagnostics use their own highlight
groups (`DiagnosticUnnecessary` and `DiagnosticDeprecated`) which
override the typical severity-based highlight groups (like
`DiagnosticUnderlineWarn`).
This can be misleading, since diagnostics about unused variables which
are warnings or errors, are shown like comments, since then only the
`DiagnosticUnnecessary` highlight group is used. Users do not see the
more eye-catching red/yellow highlight.
Solution: Instead of overriding the highlight group to
`DiagnosticUnnecessary` or `DiagnosticDeprecated`, set them in addition
to the normal severity-based highlights.
Problem: `nvim://` scheme feels more like a generalized interface that
may be requested externally, and it acts like CLI args (roughly).
This is how `vscode://` works.
Anything that behaves like an "app" or a "protocol" deserves its own
scheme. For such Nvim-owned things they will be called `nvim-xx://`.
Solution: Use `nvim-pack://confirm#<bufnr>` template for confirmation
buffer name instead of `nvim://pack-confirm#<bufnr>`.
Problem: Lockfile can become out of sync with what is actually installed
on disk when user performs (somewhat reasonable) manual actions like:
- Delete lockfile and expect it to regenerate.
- Delete plugin directory without `vim.pack.del()`.
- Manually edit lock data in a bad way.
Solution: Synchronize lockfile data with installed plugins on every
lockfile read. In particular:
1. Install immediately all missing plugins with valid lock data.
This helps with "manually delete plugin directory" case by
prompting user to figure out how to properly delete a plugin.
2. Repair lock data for properly installed plugins.
This helps with "manually deleted lockfile", "manually edited
lockfile in an unexpected way", "installation terminated due to
timeout" cases.
3. Remove unrepairable corrupted lock data and their plugins. This
includes bad lock data for missing plugins and any lock data
for corrupted plugins (right now this only means that plugin
path is not a directory, but can be built upon).
Step 1 also improves usability in case there are lazy loaded plugins
that are rarely loaded (like on `FileType` event, for example):
- Previously starting with config+lockfile on a new machine only
installs rare `vim.pack.add()` plugin after it is called (while
an entry in lockfile would still be present). This could be
problematic if there is no Internet connection, for example.
- Now all plugins from the lockfile are installed before actually
executing the first `vim.pack.add()` call in 'init.lua'. And later
they are only loaded on a rare `vim.pack.add()` call.
---
Synchronizing lockfile on its every read makes it work more robustly
if other `vim.pack` functions are called without any `vim.pack.add()`.
---
Performance for a regular startup (good lockfile, everything is
installed) is not affected and usually even increased. The bottleneck
in this area is figuring out which plugins need to be installed.
Previously the check was done by `vim.uv.fs_stat()` for every plugin
in `vim.pack.add()`. Now it is replaced with a single `vim.fs.dir()`
traversal during lockfile sync while later using lockfile data to
figure out if plugin needs to be installed.
The single `vim.fs.dir` approach scales better than `vim.uv.fs_stat`,
but might be less performant if there are many plugins that will be
not loaded via `vim.pack.add()` during startup.
Rough estimate of how long the same steps (read lockfile and normalize
plugin array) take with a single `vim.pack.add()` filled with 43
plugins benchmarking:
- Before commit: ~700 ms
- After commit: ~550 ms
Problem: Currently it is possible to have plugin in a "partial install"
state when `git clone` was successfull but `git checkout` was not.
This was done to not checkout default branch by default in these
situations (for security reasons).
The problem is that it adds complexity when both dealing with lockfile
(plugin's `rev` might be `nil`) and in how `src` and `version` are
treated (wrong `src` - no plugin on disk; wrong `version` - "partial"
plugin on disk).
Solution: Treat plugin as "installed" if both `git clone` and
`git checkout` are successful, while ensuring that not installed
plugins are not on disk and in lockfile.
This also means that if in 'init.lua' there is a `vim.pack.add()` with
bad `version`, for first install there will be an informative error
about it BUT next session will also try to install it. The solution is
the same - adjust `version` beforehand.
Problem: Installation confirmation has several usability issues:
- Choosing "No" results in a `vim.pack.add()` error. This was by
design to ensure that all later code that *might* reference
presumably installed plugin will not get executed. However, this
is often too restrictive since there might be no such code (like
if plugin's effects are automated in its 'plugin/' directory).
Instead the potential code using not installed plugin will throw
an error.
No error on "No" will also be useful for planned lockfile repair.
- List of soon-to-be-installed plugins doesn't mention plugin names.
This might be confusing if plugins are installed under different
name.
Solution: Silently drop installation step if user chose "No" and show
plugin names in confirmation text (together with their pretty aligned
sources).
