Problem:
We can resolve the `CompletionItem.detail` field but don't advertise
this capability.
Solution:
Add `detail` to
`textDocument.completion.completionItem.resolveSupport.properties`.
Problem:
The logic for generating the complete item `info` is spread across
`_lsp_to_complete_items`, the `CompleteChanged` event handler, and
`CompletionResolver:request`. This has previously caused the `info`
shown for resolved (via `completionItem/resolve`) and unresolved items
to differ.
Solution:
Centralise the logic in a new `complete_item_info` function which is now
solely responsible for determining:
1. The `info` to show.
2. The markup kind of the `info`.
3. Whether the `info` is complete.
This simplifies the interaction between the 3 functions mentioned in the
problem:
- `_lsp_to_complete_items` calls `complete_item_info` and passes along
the markup kind and whether the item needs resolving via the complete
item's `user_data`.
- The `CompleteChanged` consumes the markup kind and whether the
item needs resolving from the complete item's `user_data`.
- `CompletionResolver:request`, like `_lsp_to_complete_items` calls
`complete_item_info` again and updates the current `info` if it's
changed.
Problem:
`CompletionItem.detail` is only shown in the info popup if the server
supports `completionItem/resolve`.
Solution:
If the server doesn't support `completionItem/resolve`, prepend the
complete item `info` with `CompletionItem.detail` in a fenced codeblock,
same as we do when the server supports `completionItem/resolve`.
To ensure that completion items are displayed in the same way,
regardless of whether the server supports `completionItem/resolve`, i've
extracted out the test logic from the `selecting an item triggers
completionItem/resolve + (snippet) preview` case so that we can run the
same tests against a server which supports `completionItem/resolve` and
one which doesn't. Hopefully this should prevent the two behaviours
diverging again.
Problem:
If `CompletionItem.documentation` is populated but `detail` is not, then
`detail` is not resolved.
Solution:
Ensure that we resolve a `CompletionItem` if either `detail` or
`documentation` are not populated.
I've also removed `detail` from the popup menu since otherwise it will
be populated in both the popup menu and the info popup after the
`CompletionItem` has been resolved. I think the info popup is the best
place for it anyway as when there is a completion item with a long popup
menu entry (when `detail` is a medium/long function signature for
instance), the whole popup menu gets widened and this steals horizontal
space that could be used to display the `documentation`. Now with
`detail` and `documentation` in the info popup, they share the same
horizontal space. This also aligns with how VSCode, nvim-cmp, blink.cmp,
and mini.nvim display `detail`.
Problem:
When a resolved `CompletionItem` with kind `Snippet` populates
`textEdit` instead of `insertText`, the contents are not previewed.
Solution:
Generate the snippet preview from `textEdit.newText` as well.
Problem: Processing of a very long message may take a long time; there
is no visual feedback of work being done, and no way to abort
processing.
Calculating text height for spill indicator inhibits
performance for very long message.
Solution: Whenever writing part of a message is taking longer than 100ms,
show the first part of the message, while checking for CTRL-C.
Calculate ('wrap'-ed) text height accurately until 'lines',
use line count beyond that.
Problem:
Potential documentation drift in `tui.txt` if fields for
`$NVIM_TERMDEFS` change.
Solution:
Generate docs for `tui.txt`. Add `brief_xform` to `gen_vimdoc.lua` to
allow transforming briefs during generation.
This has been manually tested with my personal mbsync configuration and
with the following test file:
$ cat test.mbsyncrc
Channel Foo
# None may not be combined with other operations
Sync None
Sync None New
# First form
Sync Pull
Sync Push
Sync New
Sync Old
Sync Upgrade
Sync ReNew
Sync Gone
Sync Delete
Sync Flags
Sync Invalid
# Second form
Sync PullNew
Sync PullOld
Sync PullUpgrade
Sync PullReNew
Sync PullGone
Sync PullDelete
Sync PullFlags
Sync PullFull
Sync PullAll
Sync PullInvalid
Sync PushNew
Sync PushOld
Sync PushUpgrade
Sync PushReNew
Sync PushGone
Sync PushDelete
Sync PushFlags
Sync PushFull
Sync PushAll
Sync PushInvalid
Sync NewInvalid
# Multiple operations
Sync New Upgrade Gone Flags
# Mix of the two styles (an example from the mbsync manpage)
Sync PullNew PullGone Push
# Syntaxically correct, though they will raise a warning in mbsync:
Sync PullNew Pull
Sync PullNew Gone Push
closes: vim/vim#2024385eb099bf2
Co-authored-by: Cyril Roelandt <tipecaml@gmail.com>
Problem: shellescape() called without {special} flag for :! ex command
Solution: Pass 1 as second argument to shellescape() in :! contexts
related: Commit: 3fb5e58fbc63d86a3e65f1a141b0d67af2 (patch 9.2.0479:
[security]: runtime(tar): command injection in tar plugin)
129486193c
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
`nvim_create_autocmd` is too verbose and its `callback` requires extra
"nesting".
Solution:
Introduce `nvim_on`. Start using it internally. Then we can get a feel
for how it should look before making it public.
Problem:
A benefit of the old `:LspInfo` was that it showed info related to the
"current buffer" a bit more clearly.
Solution:
Highlight the "current buffer" in the LSP checkhealth report.
Problem:
filewatcher and position-encoding info is reported after the big list of
client details.
Solution:
- report the info in the top-level, not in dedicated subsections.
text-object-define is a pattern I found in tpope's plugins (e.g.
https://github.com/tpope/vim-jdaddy) which shows an elegant way to
define a text-object. (Any mistakes in the example are my fault.)
Problem:
Our documentation is incomplete or inconsistent in several ways:
- Some public APIs lack corresponding validators.
- Some public APIs lack usage examples.
- The meaning of some return values or parameters is not clearly explained.
Solution:
Add the missing validators, examples, and clarifications.
Problem:
- To share logic, creating a `vim.Range` currently creates two `vim.Pos` values
as intermediates, which causes unnecessary table allocations.
- `pos.lua` and `range.lua` contain some overlapping logic.
Solution:
Add `vim.pos._util`, a module for handling
positions represented directly by `row` and `col`.
Problem:
- A window can only have one cursor, ranges selected by the cursor are typically
obtained by marks like ">" and "<", instead of calling get_cursor() twice.
- `vim.Range` is described as end-exclusive,
but the current `range.cursor()`/`range:to_cursor()` are end-inclusive.
- Conversion between `vim.Range` and mark-indexed range can be done by
`range.mark()`/`range:to_mark()`
Solution:
Remove `range.cursor()` and `range:to_cursor()`,
Problem: `nvim_exec_autocmds({ buf = ... })` matches the target buffer, but callbacks and modelines run with the caller buffer current rather than the target buffer.
Solution: Execute the buffered path in prepared target-buffer context and restore the caller afterward.
Problem: To goto or delete a bookmark, one needs to prefix a count
for the bookmark number (e.g., "2gb" to open bookmark#2).
As the bookmark list gets or deletes entries, the numbers
keep changing, requiring listing the bookmarks with qb to
discover the desired bookmark number. Typing gb or mB
without a count targets g:netrw_bookmarklist[-1].
Solution: If no count is given to gb or mB, list all bookmarks and
prompt for a number using inputlist(), similar to tag jump
with g].
closes: vim/vim#2021135b767a090
Co-authored-by: J. Paulo Seibt <jpseibt@gmail.com>
I submitted the PR vim/vim#20232 to resolve an undesired behavior in with the
highlighter inheriting from "django.vim" and "html.vim". After
further testing I noticed the re-declaration of `djangoOperators` in
"htmldjango" is not necessary, and my conclusions where a mistake from a
not-clean test environment.
This PR reverses the effect of the commit #f03155a.
related: vim/vim#20232
closes: vim/vim#20248d004cc4f89
Co-authored-by: tecis <67809811+tecis@users.noreply.github.com>
Problem: filetype: some html files are wrongly recognized as htmlangular
Solution: Use the \< atom to anchor ng-template and ng-content to start
of word (truffle)
Prevent false-positive htmlangular detection on words containing
'ng-template' or 'ng-content' as a substring (e.g. 'song-template',
'sing-content'). Anchor both branches with \< to require a word start,
matching the \<DTD\s\+XHTML\s idiom used five lines below.
related: neovim/neovim#39778.
closes: vim/vim#20246354ab1a69e
Co-authored-by: truffle <truffleagent@gmail.com>
Problem:
Ranges represented by marks are usually end-inclusive,
but the range utilities we provided are end-exclusive.
Solution:
Add pos:to_mark(), pos.mark(), range:to_mark(), and range.mark().
Problem: User commands cannot handle single args with spaces
Solution: Add the -nargs=_ attribute (Maxim Kim)
-nargs=_ allow user commands to have a single argument with spaces.
For example given the following Test command and TestComplete function:
```
vim9script
def TestComplete(A: string, _: string, _: number): list<string>
var all = ["qqqq", "aaaa", "qq aa"]
return all->matchfuzzy(A)
enddef
command! -nargs=_ -complete=customlist,TestComplete Test echo <q-args>
```
`:Test q a<tab>` should successfully complete `qq aa`
fixes: vim/vim#20102closes: vim/vim#20189f0e874a129
Co-authored-by: Maxim Kim <habamax@gmail.com>
Problem:
After 767fbd8, typing trigger chars would open completion but the
chars were removed.
Solution:
Use filterText fallback so selected item respects typed trigger chars.
