Problem: vim.diagnostic.{underline,float,virtual_text...}.severity
will have a type warning on list-like or table (min-max) inputs,
e.g. `vim.diagnostic.config { float = { severity = { min = INFO } } }`.
Solution: Correct the typing as documented in |diagnostic-severity|.
'foldtext' can be set to an empty string to disable and render the
line with:
- extmark highlight
- syntax highlighting
- search highlighting
- no line wrapping
- spelling
- conceal
- inline virtual text
- respects `fillchars:fold`
Currently normal virtual text is not displayed
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
- Problem: One cannot easily write something like, for example:
`version_current >= {0, 10, 0}`; writing like
`not vim.version.lt(version_current, {0, 10, 0})` is verbose.
- Solution: add {`le`,`ge`} in addition to {`lt`,`gt`}.
- Also improve typing on the operator methods: allow `string` as well.
- Update the example in `vim.version.range()` docs: `ge` in place of
`gt` better matches the semantics of `range:has`.
Problem:
On devel(nightly) versions, deprecation warnings for hard-deprecated
features are not being displayed. E.g.,
- to be removed in: 0.11
- hard-deprecation since 0.10
- soft-deprecation since 0.9
then 0.10-nightly (0.10.0-dev) versions as well as 0.10.0 (stable)
should display the deprecation warning message.
Solution:
Improve the code and logic on `vim.deprecate()`, and improve
test cases with mocked `vim.version()`.
Problem: Parsed language annotations can be random garbage so
`nvim_get_runtime_file` throws an error.
Solution: Validate that `alias` is a valid language name before trying
to find a parser for it.
Problem: too vague errors for 'listchars'/'fillchars'
Solution: Include the field name in error message.
(zeertzjq)
related: #27050closes: vim/vim#138776a8d2e1634
Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com>
This function is used only in the `workspace/configuration` handler,
and does not warrant a public API because of its confusing return types.
The only caller `vim.lsp.handlers["workspace.configuration"]` is also
refactored to use `vim.tbl_get()` instead.
Problem: Modula2 filetype support lacking
Solution: Improve the Modula-2 runtime support, add additional modula2
dialects, add compiler plugin, update syntax highlighting,
include syntax tests, update Makefiles (Doug Kearns)
closes: vim/vim#6796closes: vim/vim#811568a8947069
- Luaify the detection script:
- Split the `(*!m2foo*)` and `(*!m2foo+bar*)` detection into two Lua patterns,
as Lua capture groups cannot be used with `?` and friends (as they only work
on character classes).
- Use `vim.api.nvim_buf_call()` (ew) to call `modula2#SetDialect()` to ensure
`b:modula2` is set for the given bufnr.
- Skip the syntax screendump tests. (A shame as they test some of the detection
from `(*!m2foo+bar*)` tags, but I tested this locally and it seems to work)
- Port the synmenu.vim changes from Vim9 script. (Also tested this locally)
- (And also add the missing comma for `b:browsefilter` from earlier.)
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Vim is missing a foreach() func
Solution: Implement foreach({expr1}, {expr2}) function,
which applies {expr2} for each item in {expr1}
without changing it (Ernie Rael)
closes: vim/vim#12166e79e207760
Partial port as this doesn't handle non-materialized range() lists.
vim-patch:c92b8bed1fa6
runtime(help): delete duplicate help tag E741 (vim/vim#13861)
c92b8bed1f
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Cannot easily get the list of matches
Solution: Add the matchstrlist() and matchbufline() Vim script
functions (Yegappan Lakshmanan)
closes: vim/vim#13766
Omit CHECK_LIST_MATERIALIZE(): it populates a List with numbers only,
and there is a check for strings below.
f93b1c881a
vim-patch:eb3475df0d92
runtime(doc): Replace non-breaking space with normal space (vim/vim#13868)
eb3475df0d
Co-authored-by: Yegappan Lakshmanan <4298407+yegappan@users.noreply.github.com>
The motivation for this update is Issue #15365, where background=light
is not properly set for Nvim running from an Nvim :terminal. This can be
encountered when e.g., opening a terminal to make git commits, which
opens EDITOR=nvim in the nested terminal.
Under the implementation of this commit, the OSC response always
indicates a black or white foreground/background. While this may not
reflect the actual foreground/background color, it permits 'background'
to be retained for a nested Nvim instance running in the terminal
emulator. The behaviour matches Vim.
- Add section `VIM.LPEG` and `VIM.RE` to docs/lua.txt.
- Add `_meta/re.lua` which adds luadoc and type annotations, for the
vendored `vim.re` package.
- Fix minor style issues on `_meta/lpeg.lua` luadoc for better vimdocs
generation.
- Fix a bug on `gen_vimdoc` where non-helptags in verbatim code blocks
were parsed as helptags, affecting code examples on `vim.lpeg.Cf`,
etc.
- Also move the `vim.regex` section below so that it can be located
closer to `vim.lpeg` and `vim.re`.
Typings introduced in #26032 and #26552 have a few conflicts, so we
merge and clean them up. We also fix some incorrect type annotation in
the `vim.lsp.rpc` package. See the associated PR for more details.
Summary:
- vim.rpc.Dispatchers -> vim.lsp.rpc.Dispatchers
- vim.lsp.rpc.Error -> lsp.ResponseError
- Revise docs
This commit implements a new TermRequest autocommand event and has Neovim
emit this event when children of terminal buffers emit an OSC or DCS sequence
libvterm does not handle.
The TermRequest autocommand event has additional data in the
v:termrequest variable.
Co-authored-by: Gregory Anders <greg@gpanders.com>
Problem: Some lines in the generated vim doc are overflowing, not
correctly wrapped at 78 characters. This happens when docs body contains
several consecutive 'inline' elements generated by doxygen.
Solution: Take into account the current column offset of the last line,
and prepend some padding before doc_wrap().
Improve error messages for `:InspectTree`, when no parsers are available
for the current buffer and filetype. We can show more informative and
helpful error message for users (e.g., which lang was searched for):
```
... No parser available for the given buffer:
+... no parser for 'custom_ft' language, see :help treesitter-parsers
```
Also improve the relevant docs for *treesitter-parsers*.
Problem: Keymap completion is not available
Solution: Add keymap completion (Doug Kearns)
Add keymap completion to the 'keymap' option, user commands and builtin
completion functions.
closes: vim/vim#1369281642d9d6f
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
tmux indicates its RGB support via setrgbb and setrgbf. In modern tmux
code, Tc and RGB just set setrgbb and setrgbf, so we can just check for
them.
Link: 7eb496c00c
Problem: The maximum 'statuscolumn' width and grow behavior is undocumented.
Solution: Define, use and document the maximum 'statuscolumn' width and grow behavior.
Problem:
Many decoration providers (treesitter injection highlighting, semantic
token highlighting, inlay hint) rely on the correctness of the `botline`
argument of `on_win` callback. However, `botline` can be smaller than
the actual line number of the last displayed line if some lines are
folded. In such cases, some decorations will be missing in the lines not
covered by `botline`.
Solution:
Validate `botline` when invoking `on_win`.
NOTE:
It seems that the old code was deliberately avoiding this presumably due
to performance reasons. However, I haven't experienced noticeable lag
after this change, and I believe the cost of botline computation would
be much smaller than the cost of decoration providers.
Problem:
Currently `deepcopy` hashes every single tables it copies so it can be
reused. For tables of mostly unique items that are non recursive, this
hashing is unnecessarily expensive
Solution:
Port the `noref` argument from Vimscripts `deepcopy()`.
The below benchmark demonstrates the results for two extreme cases of
tables of different sizes. One table that uses the same table lots of
times and one with all unique tables.
| test | `noref=false` (ms) | `noref=true` (ms) |
| -------------------- | ------------------ | ----------------- |
| unique tables (50) | 6.59 | 2.62 |
| shared tables (50) | 3.24 | 6.40 |
| unique tables (2000) | 23381.48 | 2884.53 |
| shared tables (2000) | 3505.54 | 14038.80 |
The results are basically the inverse of each other where `noref` is
much more performance on tables with unique fields, and `not noref` is
more performant on tables that reuse fields.
Problem:
For function definitions to be included in the vimdoc (formatted) and
to be exported as mpack data (unformatted), we had two internal
representations of the same function/API metadata in duplicate;
one is FunctionDoc (which was previously a dict), and the other is
doxygen XML DOM from which vimdoc (functions sections) was generated.
Solution:
We should have a single path and unified data representation
(i.e. FunctionDoc) that contains all the metadata and information about
function APIs, from which both of mpack export and vimdoc are generated.
I.e., vimdocs are no longer generated directly from doxygen XML nodes,
but generated via:
(XML DOM Nodes) ------------> FunctionDoc ------> mpack (unformatted)
Recursive Internal |
Formatting Metadata +---> vimdoc (formatted)
This refactoring eliminates the hacky and ugly use of `fmt_vimhelp` in
`fmt_node_as_vimhelp()` and all other helper functions! This way,
`fmt_node_as_vimhelp()` can simplified as it no longer needs to handle
generating of function docs, which needs to be done only in the topmost
level of recursion.
runtime(dist/ft): improve filetype detection for *.v (V/Verilog/Coq)
Patch provided by Dan Alt
closes: vim/vim#1379310b4f75d4c
Co-authored-by: Christian Brabandt <cb@256bit.org>
feat(diagnostic): add `vim.diagnostic.count()`
Problem: Getting diagnostic count based on the output of
`vim.diagnostic.get()` might become costly as number of diagnostic
entries grows. This is because it returns a copy of diagnostic cache
entries (so as to not allow users to change them in place).
Getting information about diagnostic count is frequently used in
statusline, so it is important to be as fast as reasonbly possible.
Solution: Add `vim.diagnostic.count()` which computes severity
counts without making copies.
This reverts commit 5cb906e91c.
They were intentionally fast-tracked.
- `parse_snippet()` because of limited scope, and given that it's kinda
semi-broken (arbitrary formatting rules, not that useful for what it
was used for)
- `extract_completion_items()` doesn't work if we want to add the LSP
completionlist capability
- `text_document_completion_list_to_complete_items()` also doesn't work
for completionlist
Style improvements:
1. Anonymous classes derived from `StructureLiteralType` should have a
better name. The class name can be also nested. Examples:
```diff
----@field serverInfo? anonym1
+---@field serverInfo? lsp._anonym1.serverInfo
```
```diff
----@field insertTextModeSupport? anonym26
+---@field insertTextModeSupport? lsp._anonym26.completionItem.insertTextModeSupport
```
2. Add one separate empty line before each `@field` definition. Without
these, empty lines the doc can look confusing because descriptions
also may contain empty lines. See `lsp.CompletionItem` for example:
```lua
---The kind of this completion item. Based of the kind
---an icon is chosen by the editor.
---@field kind? lsp.CompletionItemKind
---Tags for this completion item.
---
---@since 3.15.0
---@field tags? lsp.CompletionItemTag[]
```
It might feel like "Tags for this completion item" belongs to `kind`,
not `tags` due to the lack of separator blank lines. The following
(after this commit) should look much better:
```diff
---The kind of this completion item. Based of the kind
---an icon is chosen by the editor.
---@field kind? lsp.CompletionItemKind
+---
---Tags for this completion item.
---
---@since 3.15.0
---@field tags? lsp.CompletionItemTag[]
```
3. Escape some LSP-specific annotations that can't be recognized by
lua-ls. It'd be better to make them visible in LSP hover doc windows.
Example: `@sample ...`.
Fixes:
1. A type may extend from more than one base types (as well as mixin
types). Previously only the first base class was being considered,
resulting incomplete base classes for `@class` definitions.
Example: `InlayHintOptions` (should have both of `resolveProvider`
and `workDoneProgress`, the latter is from `WorkDoneProgressOptions`)
```diff
----@class lsp.InlayHintOptions
+---@class lsp.InlayHintOptions: lsp.WorkDoneProgressOptions
```
2. Remove `<200b>` (zero-width space) unicode characters.
3. Add the missing newline at EOF.
The purpose of this commit is to make diff clean and easy to read; to
see the diff resulted from actual changes in gen_lsp.lua, not from the
updated LSP protocol JSON data.
Ran: `nvim -l scripts/gen_lsp.lua gen --methods`
Based on 3.18.0 (2023-12-23)
The following functions should be removed in 0.12 according to the
deprecation strategy in MAINTAIN.md:
- vim.lsp.util.extract_completion_items()
- vim.lsp.util.parse_snippet()
- vim.lsp.util.text_document_completion_list_to_complete_items()
Problem: Unable to predict which byte-offset to place virtual text to
make it repeat visually in the wrapped part of a line.
Solution: Add a flag to nvim_buf_set_extmark() that causes virtual
text to repeat in wrapped lines.
As specified by MAINTAIN.md, features should be soft deprecated at first
(meaning no warnings) to give people a chance to adjust. The problem
with this approach is that deprecating a feature becomes harder than
usual as during the soft deprecation period you need to remember not to
issue a warning, and during the hard deprecation period you need to
remember to start issuing a warning.
This behavior is only enforced if the `plugin` parameter is `nil` as
plugins may not want this specific behavior.
Problem:
A region managed by an injected parser may shrink after re-running the
injection query. If the updated region goes out of the range to be
parsed, then the corresponding tree will remain outdated, possibly
retaining the nodes that shouldn't exist anymore. This results in
outdated highlights.
Solution:
Re-parse an invalid tree if its region intersects the range to be
parsed.
Use the get_language_id client option to resolve the filetype when
matching the document selector in a dynamic capability.
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
refactor(lsp): move glob parsing to vim.glob
Moving the logic for using vim.lpeg to create a match pattern from a
glob into `vim.glob`. There are several places in the LSP spec that
use globs, and it's very useful to have glob matching as a
generally-available utility.
Problem: Maximum callback depth is not configurable.
Solution: Revert patch 9.0.2103. Set 'maxfuncdepth' in test.
fixes: vim/vim#13732closes: vim/vim#13736fe583b1e59
The data to be written can be very long, so use nvim_chan_send() instead
of io.stdout:write() as the latter doesn't handle EAGAIN.
A difference of these two approaches is that nvim_chan_send() writes to
stderr, not stdout, so it won't work if client stderr is redirected.
Problem: Not all default highlight groups show their actual colors.
Solution: Refactor `vimhelp.lua` and apply it to all relevant lists (UI
groups, syntax groups, treesitter groups, LSP groups, diagnostic groups).
- Remove some unused fields
- Prefix classes with `vim.`
- Move around some functions so the query stuff is at the top.
- Improve type hints
- Rework how hl_cache is implemented
Problem: no filetype detection for execline scripts
Solution: Add filetype detection for execline
as a prior to adding syntax support for execline (see
https://github.com/djpohly/vim-execline/issues/2), i went ahead and made
the filetype detection for execline scripts.
closes: vim/vim#13689
Signed-Off-By: Mazunki Hoksaas <rolferen@gmail.com>
63210c214a
Co-authored-by: Mazunki Hoksaas <rolferen@gmail.com>
Diagnostic signs should now be configured with vim.diagnostic.config(),
but "legacy" sign definitions should go through the standard deprecation
process to minimize the impact from breaking changes.
Problem:
Treesitter highlighter's on_line was iterating all the parsed trees,
which can be quite a lot when injection is used. This may slow down
scrolling and cursor movement in big files with many comment injections
(e.g., lsp/_meta/protocol.lua).
Solution:
In on_win, collect trees inside the visible range, and use them in
on_line.
NOTE:
This optimization depends on the correctness of on_win's botline_guess
parameter (i.e., it's always greater than or equal to the line numbers
passed to on_line). The documentation does not guarantee this, but I
have never noticed a problem so far.
Currently, setting &bg at all re-initializes highlights and reloads
the active colorscheme, even if the actual value of &bg has not changed.
With https://github.com/neovim/neovim/pull/26595 this causes a
regression since &bg is set unconditionally based on the value detected
from the terminal.
Instead, only reload the colorscheme if the actual value of &bg has
changed.
runtime(doc): remove deprecation warning for gdefault
Deprecated can be misunderstood as being slated for removal; slightly
change wording to be clearer.
82f19734bf
Co-authored-by: dundargoc <gocdundar@gmail.com>
Comparing against the old value before setting matched the original
C implementation, but there is no reason to use this restriction. In
particular, this inhibits using OptionSet to determine when the option
was set. If users need to handle a case where the option _changed_, it
is easy to do so in an OptionSet autocommand using v:option_new and
v:option_old (and friends).
