| Age | Commit message (Collapse) | Author | Files |
|---|
|
Problem: Using `version=vim.version.range(...)` in plugin specification
is meant to use semver-like tags. Whether a tag is semver-like was
decided by a plain `vim.version.parse` which is not strict by default.
This allowed treating tags like `nvim-0.6` (which is usually reserved
for the latest revision compatible with Nvim<=0.6 version) like semver
tags and resulted in confusing behavior (preferring `nvim-0.6` tag
over `v0.2.2`, for example).
Solution: Use `vim.version.range(x, { strict = true })` to decide if the
tag name is semver-like or not. This allows tags like both `v1.2.3`
and `1.2.3` while being consistent in what Nvim thinks is a semver
string.
This is technically not a breaking change since it was documented that
only tags like `v<major>.<minor>.<patch>` will be recognized as
semver.
|
|
|
|
Problem:
No LuaLS types for event-data fields (ev.data). Types are only
documented ad hoc in scattered locations.
Solution:
Add runtime/lua/vim/_meta/events.lua defining vim.event.<name>.data
classes for events that provide ev.data. Reference the types from
each event's help in autocmd.txt, lsp.txt, and pack.txt.
|
|
Problem: Sometimes automatic lockfile synchronization after `:restart`
might fail, like due to bad/absent Internet connection. This would
remove failed to install entries from the lockfile (since they are not
on disk and lockfile is meant to lock the latest plugin version on
disk).
Solution: Document that this should be treated as an unwanted update and
use steps similar to "Revert plugin after an update" use case.
|
|
Problem:
On Git versions 2.13..2.26 there is a bug that prevents using
`stash --message`.
Solution:
Use the full `stash push --message` form to avoid that bug.
|
|
Problem:
`:help dev-name-common` states that "buf" should be used instead of
"buffer" but there are cases where buffer is mentioned in the lua API.
Solution:
- Rename occurrences of "buffer" to "buf" for consistency with the
documentation.
- Support (but deprecate) "buffer" for backwards compatibility.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
|
Problem: Commands that rely on Git may need its version to perform more
targeted actions (like decide which arguments are safe to use).
For performance, computing this version is delayed up until it is
needed (like to not compute on regular startup), but not done before
every Git operation (as it is too much and can be done better).
This requires storing the Git version in a variable which is currently
initiated via `vim.version.parse()` call (most probably because it was
easier to handle Lua types this way).
However, the problem is that this results in sourcing `vim.version`
and computing `vim.version.parse` on every startup even if no Git
operation would be done.
Solution: Don't call `vim.version.parse()` during `require('vim.pack')`
and ensure its more precise lazy computation.
|
|
Problem: Computing number of threads for parallel asynchronous
computation using `uv.cpu_info()` can be slow. This is especially
noticeable since it is pre-computed on every `require('vim.pack')` and
not only when parallelism is needed.
Solution: Use `uv.available_parallelism()` to compute number of threads
in a helper function.
|
|
Problem: Progress reports via `nvim_echo()` gained an ability to set
`source` and `vim.pack` doesn't currently set one.
Solution: Set `source` to 'vim.pack'. Ideally, the title then can be
something else more informative (like "update", "download", etc.), but
it is used when showing progress messages. So it has to be "vim.pack"
in this case.
|
|
Problem: JSON files should end with a trailing newline so that Unix
tools work as expected, Git doesn't report "No newline at end of file"
and to avoid noise in diffs from editors and other tools adding the
missing newline.
Solution: Add trailing newline.
|
|
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
|
|
gen_vimdoc.lua: In prepare for the upcoming release, comment-out the
"Experimental" warning for prerelease features.
|
|
Problem: Documentation of `vim.pack.update()` contains a lot of text
inside nested list. This might be a bit confusing to parse for humans
and definitely confusing to parse for neovim.io.
The description of `vim.pack` directory is not correct for Windows.
Solution: Move description of confirmation buffer in a separate
"subsection".
Use '"data" standard path' instead of '$XDG_DATA_HOME/nvim' when
documenting directory. Also use `|standard-path|` tag to link to
standard path section instead of `|stdpath()|`.
|
|
Problem: During initial "bootstrap" via lockfile synchronization, the
whole plugin specification is reconstructed from the lockfile data,
ignoring potential user changes added in the first `vim.pack.add()`.
This is enough in most situations since it is the only data needed
for actual installation.
However, this affects specification passed to `PackChanged[Pre]`
events. In particular, `data` field is missing which can be a problem
if there is a `PackChanged kind=install` hook that uses that field
(like with some kind of `build` method used during install).
And there might be different `version` set in `vim.pack.add()`.
Solution: Pass the `specs` input of the first `vim.pack.add()` down to
lockfile synchronization and use it to reconstruct plugin
specification for the to-be-installed plugin. If present among the
user's `specs`, it is used but with forced `src` from the lockfile (as
it is the one used during installation).
Note that this still has a caveat when using separate
`vim.pack.add()`, as only the specs from the first input (when the
lockfile synchronization happens) is taken into account.
|
|
Problem: Executing `nvim_buf_delete()` does not guarantee that the
window which shows the buffer is going to close after `:write` or
`:quit`. In particular, if there is no listed buffer present.
Solution: Explicitly close the window that was created for confirmation
buffer. Use `pcall` to catch cases when the window was already closed
or when it is the last window.
|
|
Otherwise, output will be concatenated without newlines.
TODO: the ":redraw!" call can be dropped entirely after ui2 becomes the default.
|
|
|
|
|
|
|
|
Problem: `vim.pack.update()` doesn't update source's default branch if
it has changed on the remote. It can be done by executing
`git remote set-head origin --auto` for every plugin on every update,
but it feels like too much extra work (which requires Internet
connection) for a very rare use case.
This matters since `version = nil` will keep pointing to previous
default branch even after `vim.pack.update()`.
Solution: Document that in order for `version = nil` to point to the
source's new default branch, perform clean re-install.
|
|
Problem: Installing plugin with submodules doesn't check out their
state (due to `git clone --no-checkout` to not end up with default
branch code in case of invalid `version`).
Updating a plugin with submodules doesn't update their state.
Solution: Update `git_checkout` helper to account for submodules.
Another approach would be `git checkout --recurse-submodules ...`,
but that doesn't seem to allow `--filter=blob:none` for submodules,
which is nice to have.
Also make `git_clone` wrapper simpler since `--no-checkout` makes
`--recurse-submodules` and `--also-filter-submodules` do nothing.
|
|
Problem: Installing plugin is done via `git clone --no-checkout ...`
(to not end up with default branch code in case of invalid `version`).
This leaves cloned repo in a state that `git stash` will actually add
an entry to the stash list. Although not critical, better to not have
that if possible.
Solution: explicitly skip `git stash` step in checkout during install.
|
|
Problem: Plugin directory ('.../pack/core/opt') may be missing while
lockfile is present. Like after discarded attempt to install plugins.
Solution: Ensure plugin directory is created on first `vim.pack` use.
|
|
|
|
|
|
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: There are two fairly common workflows that involve lockfile and
can be made more straightforward in `vim.pack`:
1. Revert latest update. Like if it introduced unwanted behavior.
2. Update to a revision in the lockfile. Like if already updated
on another machine, verified that everything works, `git add` +
`git commit` + `git push` the config, and want to have the same
plugin states on current machine.
Solution: Make `update` allow `opts.target`. By default it uses
`version` from a plugin specification (like a regular "get new changes
from source" workflow). But it also allows `"lockfile"` value to
indicate that target revision after update should be taken from the
current lockfile verbatim.
With this, the workflows are:
1. Revert (somehow) to the lockfile before the update, restart, and
`vim.pack.update({ 'plugin' }, { target = 'lockfile' })`. If Git
tracked, revert with `git checkout HEAD -- nvim-pack-lock.json`.
For non-VCS tracked lockfile, the revisions can be taken from the
log file. It would be nicer if `update()` would backup a lockfile
before doing an update, but that might require discussions.
2. `git pull` + `:restart` +
`vim.pack.update(nil, { target = 'lockfile' })`.
The only caveats are for new and deleted plugins:
- New plugins (not present locally but present in the lockfile)
will be installed at lockfile revision during restart.
- Deleted plugins (present locally but not present in the
lockfile) will still be present: both locally *and* in the
lockfile. They can be located by
`git diff -- nvim-pack-lock.json` and require manual
`vim.pack.del({ 'old-plugin1', 'old-plugin2' })`.
|
|
|
|
Problem: Changing `src` of already installed plugin currently takes
effect immediately inside `vim.pack.add()` and acts as "delete and
later fresh install". Although more robust, this might lead to
unintentional data loss (since plugin is deleted) if the plugin was
manually modified or the new source is not valid.
Also this introduces unnecessary differentiation between "change
`version`" and "change `src`" of already installed plugin.
Solution: Require an explicit `vim.pack.update()` to change plugin's
source. It is done by conditionally changing `origin` remote of the
Git repo. The effect does not require update confirmation in order to
have new changes fetched from the new `src` right away.
If in the future there are more types of plugins supported (i.e. not
only Git repos), also do extra work (like delete + install) during
`vim.pack.update()`.
|
|
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: Lockfile can become out of sync with what is actually installed
on disk when user performs (somewhat reasonable) manual actions like:
- Delete lockfile and expect it to regenerate.
- Delete plugin directory without `vim.pack.del()`.
- Manually edit lock data in a bad way.
Solution: Synchronize lockfile data with installed plugins on every
lockfile read. In particular:
1. Install immediately all missing plugins with valid lock data.
This helps with "manually delete plugin directory" case by
prompting user to figure out how to properly delete a plugin.
2. Repair lock data for properly installed plugins.
This helps with "manually deleted lockfile", "manually edited
lockfile in an unexpected way", "installation terminated due to
timeout" cases.
3. Remove unrepairable corrupted lock data and their plugins. This
includes bad lock data for missing plugins and any lock data
for corrupted plugins (right now this only means that plugin
path is not a directory, but can be built upon).
Step 1 also improves usability in case there are lazy loaded plugins
that are rarely loaded (like on `FileType` event, for example):
- Previously starting with config+lockfile on a new machine only
installs rare `vim.pack.add()` plugin after it is called (while
an entry in lockfile would still be present). This could be
problematic if there is no Internet connection, for example.
- Now all plugins from the lockfile are installed before actually
executing the first `vim.pack.add()` call in 'init.lua'. And later
they are only loaded on a rare `vim.pack.add()` call.
---
Synchronizing lockfile on its every read makes it work more robustly
if other `vim.pack` functions are called without any `vim.pack.add()`.
---
Performance for a regular startup (good lockfile, everything is
installed) is not affected and usually even increased. The bottleneck
in this area is figuring out which plugins need to be installed.
Previously the check was done by `vim.uv.fs_stat()` for every plugin
in `vim.pack.add()`. Now it is replaced with a single `vim.fs.dir()`
traversal during lockfile sync while later using lockfile data to
figure out if plugin needs to be installed.
The single `vim.fs.dir` approach scales better than `vim.uv.fs_stat`,
but might be less performant if there are many plugins that will be
not loaded via `vim.pack.add()` during startup.
Rough estimate of how long the same steps (read lockfile and normalize
plugin array) take with a single `vim.pack.add()` filled with 43
plugins benchmarking:
- Before commit: ~700 ms
- After commit: ~550 ms
|
|
|
|
Problem: Currently it is possible to have plugin in a "partial install"
state when `git clone` was successfull but `git checkout` was not.
This was done to not checkout default branch by default in these
situations (for security reasons).
The problem is that it adds complexity when both dealing with lockfile
(plugin's `rev` might be `nil`) and in how `src` and `version` are
treated (wrong `src` - no plugin on disk; wrong `version` - "partial"
plugin on disk).
Solution: Treat plugin as "installed" if both `git clone` and
`git checkout` are successful, while ensuring that not installed
plugins are not on disk and in lockfile.
This also means that if in 'init.lua' there is a `vim.pack.add()` with
bad `version`, for first install there will be an informative error
about it BUT next session will also try to install it. The solution is
the same - adjust `version` beforehand.
|
|
Problem: Installation confirmation has several usability issues:
- Choosing "No" results in a `vim.pack.add()` error. This was by
design to ensure that all later code that *might* reference
presumably installed plugin will not get executed. However, this
is often too restrictive since there might be no such code (like
if plugin's effects are automated in its 'plugin/' directory).
Instead the potential code using not installed plugin will throw
an error.
No error on "No" will also be useful for planned lockfile repair.
- List of soon-to-be-installed plugins doesn't mention plugin names.
This might be confusing if plugins are installed under different
name.
Solution: Silently drop installation step if user chose "No" and show
plugin names in confirmation text (together with their pretty aligned
sources).
|
|
Problem: Relaxing minimal Git version did not fully preserve previous
behavior in case there no `git` executable. Instead it showed the same
error as if after `vim.system({ 'does_not_exist' })`.
Solution: Show a more direct "No `git` executable" error message.
|
|
Problem: No example workflow of how to revert after a bad update.
Solution: Add example workflow of how to revert after a bad update.
In future this might be improved by utilizing other `vim.pack`
features or via a dedicated function (like `vim.pack.restore()` that
restores all installed plugins to a state from the lockfile).
|
|
Problem: Changing `src` of an existing plugin cleanly requires manual
`vim.pack.del()` prior to executing `vim.pack.add()` with a new `src`.
Solution: Autodetect `src` change for an existing plugin (by comparing
against lockfile data). If different - properly delete immediately and
treat this as new plugin installation.
Alternative solution might be to update `origin` remote in the
installed plugin after calling `vim.pack.update()`. Although, doable,
this 1) requires more code; and 2) works only for Git plugins (which
might be not the only type of plugins in the future). Automatic
"delete and clean install" feels more robust.
|
|
Problem: Plain `vim.pack.add()` calls (with default `opts.load`) does
not fully work if called inside 'plugin/' runtime directory. In
particular, 'plugin/' files of newly added plugins are not sourced.
This is because `opts.load` is `false` during the whole startup, which
means `:packadd!` is used (modify 'runtimepath' but not force source
newly added 'plugin/' files).
This use case is common due to users organizing their config as
separate files in '~/.config/nvim/plugin/'.
Solution: Use newly added `v:vim_did_init` to decide default `opts.load`
value instead of `v:vim_did_enter`.
|
|
Problem: Current requirement is Git>=2.36 as `--also-filter-submodules`
flag for `git clone` was introduced there. This is problematic since
default Git version on Ubuntu 22.04 is 2.34.
Solution: Relax minimal Git version to be (at least) 2.0 by selectively
applying necessary flags based on the current Git version.
As 2.0.0 was released in 2014-05-28 (almost the same age as Neovim
project itself), it is reasonable to drop any mention and checks on
minimal version altogether.
|
|
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: Using abbreviated version of commit hashes might be unreliable
in the long term (although highly unlikely).
Solution: Use full hashes in lockfile and revision description (in
confirmation buffer and log). Keep abbreviated hashes when displaying
update changes (for brevity).
|
|
Problem: No examples of how to use `PackChanged[Pre]` for plugin hooks.
Solution: Add examples of creating plugin hooks.
|
|
Problem: `PackChanged[Pre]` events with `kind=update` are triggered both
during plugin's initial installation and after already installed
plugin was updated.
It was a deliberate decision to allow writing only a single update
hook to act as a dedicated "build" entry point (like execute `make` or
`cargo build —release`). This mimics how other plugin managers have a
single "build" command.
This was a result of 'mini.deps' experience with the different
approach: "update" hooks are not run during install. This proved to be
confusing as it requires to write two hooks. But also the reason might
be that 'mini.deps' names it "checkout" hook instead of "update".
However, the `vim.pack` event approach makes it lower cost to handle
separate "update" and "install" events. Something like
`if ev.data.kind == 'install' or ev.data.kind == 'update' then`
instead of two autocommands.
Plus this makes clearer separation of events.
Solution: do not trigger `PackChanged[Pre] kind=update` event during
install.
|
|
Problem: Inside `PackChanged[Pre]` callbacks it might be useful to tell
if the affected plugin is active or not. It is already possible via
extra `vim.pack.get({ 'plug-name' })[1].active`, but it is not quite
user-friendly for something that might be needed frequently in real
world use cases.
Solution: Supply extra `active` event data field.
|
|
Refs: #36037
|
|
Problem: If plugin was intended to install but there were errors (like
if there is a typo in `src`), lockfile still includes its entry.
This leads to all source of problems (like not correct `get()` output,
not working `update()`, etc.).
Solution: Explicitly account for plugins that were not installed.
Alternative solution might be to write a safe
`lock_set(plug, field, value)` wrapper (which sets field for a correct
`plugins` entry in the lockfile Lua table) and use it after install
to detect the change in `version`. However, this always requires
an extra pass through plugins on every startup, which is suboptimal.
Optimizing for the "happy path" should be a priority in `add()`.
|
