The flakiness happens because get() uses vim.schedule(), and a following
key may be processed before the scheduled event. Use poke_eventloop() to
ensure that the scheduled event is processed.
Problem: Some environment variables which are useful when working inside
a bare repository can affect any Git operation.
Solution: Explicitly unset problematic environment variables.
Problem:
Force resolve `spec.version` overrides the information about whether
a user supplied `version` or not. Knowing it might be useful in some use
cases (like comparing to previously set `spec` to detect if it has
changed).
Solution:
Do not resolve `spec.version`. This also improves speed when triggering
events and calling `get()`.
- Place default branch first when listing all branches.
- Use correct terminology in `get_hash` helper.
- Do not return `{ '' }` if there are no tags.
Problem:
There is no way to get more information about installed plugins, like
current revision or default branch (necessary if resolving default
`spec.version` manually). As computing Git data migth take some time,
also allow `get()` to limit output to only necessary set of plugins.
Solution:
- introduce arguments to `get(names, opts)`, which follows other
`vim.pack` functions. Plugin extra info is returned by default and
should be opt-out via `opts.info = false`.
- Examples:
- Get current revision: `get({ 'plug-name' })[1].rev`
- Get default branch: `get({ 'plug_name' })[1].branches[1]`
- `update()` and `del()` act on plugins in the same order their names
are supplied. This is less surprising.
- default `opts.info` to `true` since this simplifies logic for the
common user, while still leaving the door open for a faster `get()` if
needed.
Problem: Progress reports use plain `nvim_echo()` with manually
constructed messages and populate history on every call.
Solution: Use `nvim_echo()` with newly added `kind=progress` which (at
least for now) is meant to be a unified interface for showing progress
report. Also save in history only first and last progress report
messages.
Problem:
Hover response of MarkedString[] where the first element contains a
language identifier treated as empty.
Solution:
Fix empty check to handle case of MarkedString[] where the first element
is a pair of a language and value.
Problem:
The load function in opts was difficult to use if you wished to
customize based on the plugin being loaded.
You could get the name, but without some way to mark a spec, that was of
limited usefulness unless you wanted to hardcode a list of names in the
function, or write a wrapper around the whole thing
Solution:
Allow users to provide an arbitrary data field in plugin specs so that
they may receive info as to how to handle that plugin in load, get() and
events, and act upon it
Co-authored-by: BirdeeHub <birdee@localhost>
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem:
Buffer-updates on_detach callback is invoked before buf_freeall(), which
deletes autocmds of the buffer (via apply_autocmds(EVENT_BUFWIPEOUT,
...)). Due to this, buffer-local autocmds executed in on_detach (e.g.,
LspDetach) are not actually invoked.
Solution:
Call buf_updates_unload() before buf_freeall().
Problem: No way to skip install confirmation in `add()`. Having install
confirmation by default is a more secure design. However, users are
usually aware of the fact that plugin will be installed and there is
currently no way to skip confirmation.
Plus it can introduce inconvenience on the clean config initialization
if it is modularized with many `vim.pack.add()` calls (leads to
confirming installation many times in a row).
Solution: Add `opts.confirm` option that can skip install confirmation.
Problem: No way to have full control over how plugin is loaded.
Although `:packadd!` has small side effects (only adds plugin
directory to 'runtimepath'; and maybe its 'after/' subdirectory), it
still has side effects. For example, 'plugin/' directories are still
loaded during startup (as part of `:h load-plugins`).
Solution: Allow function `opts.load` that has full control over how
plugin is loaded.
Problem: the `load=true` in `vim.pack.add()` means that `:packadd` is
executed even during startup. This leads to force source of 'plugin/',
which breaks the intended loading order (`:h load-plugins`) and
results into sourcing them twice. This also makes it ignore
`--noplugin` argument.
Using `:packadd!` during startup is more appropriate, while `:packadd`
afterwards is still more favorable to actually force 'plugin/' source
(as there is no pre-defined mechanism that will load them later).
Solution: have `load=false` default during startup, `true` - afterwards.
- Add delimiter between function signature and documentation, matching hover formatting
- Show title only if there are multiple clients or multiple signatures
- Avoid duplicating the title inside the window if it's already shown in the border
Problem: make_floating_popup_options only shows when opts.border is explicitly set, ignoring global winborder setting
Solution: check both opts.border and vim.o.winborder when determining whether to show title
The cursor movement autocommand can not detect when the final tabstop $0
is directly adjacent to another tabstop, which prevents ending the
snippet session. The fix is an early return when jumping.
Problem:
Previously, 'null' value in LSP responses were decoded as 'nil'.
This caused ambiguity for fields typed as '? | null' and led to
loss of explicit 'null' values, particularly in 'data' parameters.
Solution:
Decode all JSON 'null' values as 'vim.NIL' and adjust handling
where needed. This better aligns with the LSP specification,
where 'null' and absent fields are distinct, and 'null' should
not be used to represent missing values.
This also enables proper validation of response messages to
ensure that exactly one of 'result' or 'error' is present, as
required by the JSON-RPC specification.
**Problem:** For unchanged document diagnostic reports, the `resultId`
is ignored completely, even though it should still be saved for the
request (in fact, the spec marks it as mandatory for unchanged reports,
so it should be extra important).
**Solution:** Always store the `resultId`.
Problem:
From https://matrix.to/#/!cylwlNXSwagQmZSkzs:matrix.org/$Ofj-TFIsEMbp0O9OhE8xuZSNi-nhRLtZTOgs6JRLNrs?via=matrix.org&via=gitter.im&via=mozilla.org
In lesson 2.6, users are asked to remove the second, forth and fifth
lines with `dd` command, then they are asked to undo twice to make the
text go back to original state. But after that, the mark ✗ appears
again, which confuses the user because they think they do something
wrong. This is a limitation with the current implementation, which is
based on line number only.
Solution:
Reimplement interactive marks as extmarks in Lua. This also make the
feature less fragile, as users can remove, add some arbitrary lines
without breaking the interactive marks.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: Health check floating window gets closed when pressing 'gO' to show TOC because LSP floating preview system auto-closes on BufEnter events triggered by :lopen.
Solution: Temporarily disable BufEnter event for the current window during TOC operations and adjust window layout to prevent overlap.
Problem:
Closes#31453
Solution:
Introduce `vim.lsp.Capability`, which may serve as the base class for
all LSP features that require caching data. it
- was created if there is at least one client that supports the specific method;
- was destroyed if all clients that support the method were detached.
- Apply the refactor for `folding_range.lua` and `semantic_tokens.lua`.
- Show active features in :checkhealth.
Future:
I found that these features that are expected to be refactored by
`vim.lsp.Capability` have one characteristic in common: they all send
LSP requests once the document is modified. The following code is
different, but they are all for this purpose.
- semantic tokens:
fb8dba413f/runtime/lua/vim/lsp/semantic_tokens.lua (L192-L198)
- inlay hints, folding ranges, document color
fb8dba413f/runtime/lua/vim/lsp/inlay_hint.lua (L250-L266)
I think I can sum up this characteristic as the need to keep certain
data synchronized with the latest version computed by the server.
I believe we can handle this at the `vim.lsp.Capability` level, and
I think it will be very useful.
Therefore, my next step is to implement LSP request sending and data
synchronization on `vim.lsp.Capability`, rather than limiting it to the
current create/destroy data approach.
Problem:
Error when adding a plugin will make all following plugins not
`:packadd`ed
Solution:
- add() should handle errors from :packadd with pcall()
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: tests: need a test for the new-style tutor.tutor, patch
9.1.1384 broke the expected positions for the signs
Solution: Update all number keys in tutor.tutor.json to match the
correct line numbers in tutor.tutor, replace tabs by spaces,
add a screen-dump test to verify it does not regress
(Pham Bình An)
closes: vim/vim#17416a541f1de2b
Problem:
In LSP configs, the function form of `cmd()` cannot easily get the
resolved root dir (workspace). One of the main use-cases of a dynamic
`cmd()` is to be able to start a new server whose binary may be located
*in the workspace* ([example](https://github.com/neovim/nvim-lspconfig/pull/3912)).
Compare `reuse_client()`, which also receives the resolved config.
Solution:
Pass the resolved config to `cmd()`.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: A custom property containing a pair of square brackets will be
treated as a section.
Solution: Change the logic parsing a section, remove the first match
regex `%b[]`.
Signed-off-by: fortime <palfortime@gmail.com>
