| Age | Commit message (Collapse) | Author | Files |
|---|
|
Problem:
With GIT_DIR/GIT_WORK_TREE set, the LSP on the vim.pack.update()
confirmation buffer does not show the correct git log on hover.
Solution:
Temporarily remove the git vars from the environment.
|
|
Problem: If the lockfile points to the revision that is not on disk, the
`:checkhealth vim.pack` suggests to run `vim.pack.update()`. Although
usually it should resolve the problem, it is not always the case: like
if the state on disk is already the latest available.
Solution: Add an extra suggestion with a more drastic measure by
manually removing `rev` field from the lockfile for it to be repaired
after the `:restart`.
|
|
Problem: It is possible (and documented in `:h vim.pack`) that plugin's
`src` uses "insteadOf" Git config. In that case comparing it directly
to repo's `origin` will error.
Solution: Add extra check that lockfile's `src` is not equal to repo's
`origin` when taking Git's "insteadOf" into account.
However, still report the original lockfile's `src` in the
`:checkhealth` output, as it seems to be a clearer indication of what
actually is wrong.
|
|
refactor(lua): add integer coercion helpers
Add vim._tointeger() and vim._ensure_integer(), including optional base
support, and switch integer-only tonumber()/assert call sites in the Lua
runtime to use them.
This also cleans up related integer parsing in LSP, health, loader, URI,
tohtml, and Treesitter code.
supported by AI
|
|
|
|
Problem: No `:checkhealth` entry.
Solution: Add `:checkhealth vim.pack`. Design it around validating
assumptions about `vim.pack` usage and giving actionable advice to fix
possible issues. In particular:
- Basic requirements are met: `git` executable, lockfile, and
plugin directory are present.
- Lockfile has correct shape (json with correct field types) and
aligns with plugins on disk (revision and source are as expected).
- Plugin directory has proper entries: all directories, in the state
that `vim.pack` might leave them.
Also notify if there are not active plugins. Those might be lazy
loaded (okay) or removed an entry from the config without
`vim.pack.del()` (not okay).
Make sure that it passes with brief feedback if it doesn't look like
`vim.pack` is being used.
Duplicate check for `git` executable (on top of already existing
very similar 'health/health.lua' check for "External tools") to have
it shown after `:checkhealth vim.pack`. Keep the other check for more
exposure and possibly for other plugins to reuse it.
|
|
|
|
Problem: Deleting active plugins can lead to a situation when it is
reinstalled after restart.
Solution: Suggest "delete" code action only for not active plugins.
Whether a plugin is not active is visible by a hint in its header.
|
|
Problem: After `vim.pack.update()` it is not clear if plugin is active
or not. This can be useful to detect cases when plugin was removed
from 'init.lua' but there was no `vim.pack.del()`.
Solution: Add ` (not active)` suffix with distinctive highlighting to
header of plugins that are not active.
It will also be shown in in-process LSP document symbols to have quick
reference about which plugins are not active.
|
|
Problem: Using `vim.pack.del()` to delete active plugin can lead to
a situation when this plugin is reinstalled after restart. Removing
plugin from 'init.lua' is documented, but can be missed.
Solution: Make `del()` only remove non-active plugins by default and
throw an informative error if there is an active plugin.
Add a way to force delete any plugin by adding `opts.force`. This also
makes `del()` signature be the same as other functions, which is nice.
|
|
Problem: There is now way to run `update()` without Internet connection
while there are some workflows that do not require it. Like "switch
plugin version" and "revert latest update".
Solution: Add `opts.offline` to `update()`. This also allows now to
treat `vim.pack.update(nil, { offline = true })` as a way to
interactively explore currently installed plugins.
|
|
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: Confirmation buffer is named with `nvim-pack://` as scheme
prefix and uses buffer id (needed for in-process LSP) as one an entry
in the "hierarchical part".
Solution: Use `nvim://pack-confirm#<buf>` format with a more ubiquitous
`nvim://` prefix and buffer id at the end as the optional fragment.
|
|
Problem: In some areas plugin's revision is named "state". This might be
confusing for the users.
Solution: Consistently use "revision" to indicate "plugin's state on
disk".
|
|
Problem: No way to granularly operate on plugins when inside
confirmation buffer.
Solution: Implement code actions for in-process LSP that act on "plugin
at cursor":
- Update (if has updates).
- Skip updating (if has updates).
- Delete.
Activate via default `gra` or `vim.lsp.buf.code_action()`.
|
|
Problem: No built-in plugin manager
Solution: Add built-in plugin manager
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
|
