To avoid repeatedly requesting a buffer multiple times before a request is completed, the current implementation puts the requested buffer into the active_refreshes table before requesting.
But since we only remove the buffer from active_refreshes in the lsp-handler of textDocument/codeLens, this will cause if the user sends a request that cannot trigger lsp-handler (for example, if there is an LSP server attached to the current buffer, and especially when the user creates an autocmd which performs vim.lsp.codelens.refresh after the BufEnter event is triggered like in the document example), this buffer will be put into active_refreshes, and there is no way to remove it, which will result in all subsequent vim.lsp.codelens.refresh not requesting textDocument/codeLens.
According to the LSP specification, the CodeLens.command is optional but the CodeLens.command.command is not optional, which means the correct representation of a display-only code lens is indeed one with a command with a title to display and an empty string as command.
Problem: filetype: R history files are not recognized
Solution: Detect '.Rhistory' files as r filetype
(Wu, Zhenyu)
closes: vim/vim#14440fc21b6437c
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
runtime(doc): Normalise builtin-function optional parameter formatting
These should generally be formatted as func([{arg}]) and referenced as
{arg} in the description.
closes: vim/vim#144389cd9e759ab
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Design
- Enable commenting support only through `gc` mappings for simplicity.
No ability to configure, no Lua module, no user commands. Yet.
- Overall implementation is a simplified version of 'mini.comment'
module of 'echasnovski/mini.nvim' adapted to be a better suit for
core. It basically means reducing code paths which use only specific
fixed set of plugin config.
All used options are default except `pad_comment_parts = false`. This
means that 'commentstring' option is used as is without forcing single
space inner padding.
As 'tpope/vim-commentary' was considered for inclusion earlier, here is
a quick summary of how this commit differs from it:
- **User-facing features**. Both implement similar user-facing mappings.
This commit does not include `gcu` which is essentially a `gcgc`.
There are no commands, events, or configuration in this commit.
- **Size**. Both have reasonably comparable number of lines of code,
while this commit has more comments in tricky areas.
- **Maintainability**. This commit has (purely subjectively) better
readability, tests, and Lua types.
- **Configurability**. This commit has no user configuration, while
'vim-commentary' has some (partially as a counter-measure to possibly
modifying 'commentstring' option).
- **Extra features**:
- This commit supports tree-sitter by computing `'commentstring'`
option under cursor, which can matter in presence of tree-sitter
injected languages.
- This commit comments blank lines while 'tpope/vim-commentary' does
not. At the same time, blank lines are not taken into account when
deciding the toggle action.
- This commit has much better speed on larger chunks of lines (like
above 1000). This is thanks to using `nvim_buf_set_lines()` to set
all new lines at once, and not with `vim.fn.setline()`.
Problem:
Some servers don't report progress during initialize unless the client
sets the `workDoneToken`
See https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initiatingWorkDoneProgress
In particular:
> There is no specific client capability signaling whether a client will
> send a progress token per request. The reason for this is that this is
> in many clients not a static aspect and might even change for every
> request instance for the same request type. So the capability is signal
> on every request instance by the presence of a workDoneToken property.
And:
> Servers can also initiate progress reporting using the
> window/workDoneProgress/create request. This is useful if the server
> needs to report progress outside of a request (for example the server
> needs to re-index a database). The token can then be used to report
> progress using the same notifications used as for client initiated
> progress.
So far progress report functionality was relying entirely on the latter.
Solution:
Set a `workDoneToken`
Closes https://github.com/neovim/neovim/issues/27938
Ref #21393
- Move default user commands to _defaults.lua as that now contains all
kinds of defaults rather than just default mappings and menus.
- Remove the :aunmenu as there are no menus when _defaults.lua is run.
Problem: Dialog for file changed outside of Vim not tested.
Solution: Add a test. Move FileChangedShell test. Add 'L' flag to
feedkeys().
5e66b42aae
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: filetype: typespec files are not recognized
Solution: Detect '*.tsp' files as typespec
(Hilmar Wiegand)
Specs is at https://typespec.io/closes: vim/vim#143926c9f4f98f1
Co-authored-by: Hilmar Wiegand <me@hwgnd.de>
Problem: Injecting languages for file redirects (e.g., in bash) is not
possible.
Solution: Add `@injection.filename` capture that is piped through
`vim.filetype.match({ filename = node_text })`; the resulting filetype
(if not `nil`) is then resolved as a language (either directly or
through the list maintained via `vim.treesitter.language.register()`).
Note: `@injection.filename` is a non-standard capture introduced by
Helix; having two editors implement it makes it likely to be upstreamed.
Problem: Filetype detection fails if file name ends in many '~'.
Solution: Strip multiple '~' at the same time. (closesvim/vim#12553)
c12e4eecbb
In Nvim this already works as Lua filetype detection isn't subject to
such a small recursion limit as autocommands, but it still makes sense
to avoid unnecessary recursion.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: filetype: rock_manifest and config.ld files are not recognized
Solution: Detect 'rock_manifest' and 'config.ld' as lua
(Wu, Zhenyu)
closes: vim/vim#14370a917bd58bd
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: fontconfig files are not recognized
Solution: detect 'fonts.conf' as xml
(Wu, Zhenyu)
closes: vim/vim#14367a2c27b01dc
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: zsh theme, history and zunit files are not
recognized.
Solution: Detect '.zsh_history', '*.zsh-theme' and '*.zunit' as zsh
(Wu, Zhenyu)
closes: vim/vim#14366a55a22a1a3
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: bash history files are not recognized
Solution: detect .bash-history and .bash_history files as bash
(Wu, Zhenyu)
closes: vim/vim#1436584ce55001a
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: netrw history file is not recognized
Solution: Detect .netrwhist as vim files (Wu, Zhenyu)
closes: vim/vim#14364abbb4a4f70
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: mysql history files are not recognized
Solution: Detect .mysql_history as mysql
(Wu, Zhenyu)
closes: vim/vim#143626b285c8cfd
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: supertux files are not recognized
Solution: Supertux uses lisp to store hotkeys in config and game stage information,
so add a pattern for supertux files.
(Wu, Zhenyu)
Reference: https://github.com/SuperTux/supertux/wiki/S-Expressioncloses: vim/vim#143564ff83b904e
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: support for Intel HEX files is lacking
Solution: Add more file extensions that are typical for Intel HEX files
(Wu, Zhenyu)
Reference: https://en.wikipedia.org/wiki/Intel_HEXcloses: vim/vim#14355e523dd9803
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
The `callHierarchy` function should warn the user when
`textDocument/prepareCallHierarchy` didn't resolve an entity and
return, rather than calling the `callHierarchy/{incoming,outgoing}Calls`
method with an empty object - which is encoded as an empty list (which
doesn't respect language server specification for the
`callHierarchy/incomingCalls` call).
Backslashes are valid characters in unix style paths.
Fix the conversion of backslashes to forward slashes in several `vim.fs`
functions when not on Windows. On Windows, backslashes will still be converted
to forward slashes.
Problem: Two unrelated things are tested by a single test.
Solution: Split it into two, restoring the old Test_brace_single_line().
Add missing cleanup to some tests.
(zeertzjq)
closes: vim/vim#14323ad493ef3ea
Problem: Page-wise scrolling with Ctrl-D/Ctrl-U implements
it's own logic to change the topline and cursor.
More logic than necessary for scrolling with Ctrl-F/Ctrl-B
was removed in patch 9.1.0211.
Solution: Re-use the logic from Ctrl-E/Ctrl-Y/Ctrl-F/Ctrl-B while
staying backward compatible as much as possible.
Restore some of the logic that determined how many lines will
be scrolled (Luuk van Baal)
5a2e3ec9ac
Problem: Page-wise scrolling with Ctrl-F/Ctrl-B implements
it's own logic to change the topline and cursor.
In doing so, skipcol is not handled properly for
'smoothscroll', and virtual lines.
Solution: Re-use the logic from Ctrl-E/Ctrl-Y while staying
backward compatible as much as possible.
b9f5b95b7b
Problem: filetype: support for gnuplot files is lacking
Solution: Also detect *.gnuplot files
(RobbiZ98)
closes: vim/vim#142433a6bd0c5c7
Co-authored-by: RobbiZ98 <113035863+RobbiZ98@users.noreply.github.com>
