Problem: Some use cases might lead to `vim.pack.add()` failing to
`:packadd` a plugin because of missing entry in 'packpath'. Like with
`nvim --clean` or manually setting `$XDG_DATA_HOME` during startup.
Solution: Document it. A more proactive approach can be ensuring correct
'packpath' entry, but it is currently somewhat verbose to do (due to
having to adjust for Windows using `\` in 'packpath' entries).
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: 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.
Problem: Left (`<` prefix) and right (`>` prefix) parts of update
changelog come in not fixed order: it can be left-right or right-left.
Solution: Ensure left-right order.
Problem: New version suggestions in update confirmation buffer might
include semver tags that were committed later but for versions that
are not greater than current. Like if versions committed in order
`v0.2.0` - `v0.3.0` - `v0.2.1` - `v0.3.1`, then when on `v0.3.0` both
`v0.2.1` and `v0.3.1` are suggested, but only the latter is newer as
a version. This is because those tags are computed with post-processed
`git tag --list --contains HEAD`.
Solution: Compute all semver tags and filter only those greater than the
latest version available at HEAD.
Problem: Both `PackChangedPre` and `PackChanged` contain |event-data|
with plugin's `spec`. It looks like a good idea to have all its
triggers contain the same format across all kinds ("install",
"update", "delete"). There are several choices:
- Have it be as verbatim as supplied to `vim.pack.add()`, i.e. can
be either string or table. A bit too ambiguous.
- Have it be table with `src` and `name` inferred. This requires
less work for "install", but more work for "update" and "delete"
(since they use `vim.pack.get()` which already infers default
`version`).
- Have it be table with *all* defaults made explicit. This looks
like the best approach, but requires extra care to only infer
default `version` when needed (i.e. avoid inferring during regular
load) because it is costly in terms of startup time.
This might also introduce inconsistency when dealing with
lockfile(s) as information there should be as close to what user
supplied as possible. Address that when dealing with lockfile.
Solution: Ensure explicit `version` in all events where possible.
Problem: Currently `update()` and `del()` silently ignore input plugin
names that are not for already installed plugin. This might lead to
confusion because they are not explicitly reported.
Solution: Check that all input names are for installed plugins and error
otherwise.
Problem: using `print()` to show progress report writes to `stdout` when
in `--headless` mode (interferes with the testing output) and doesn't
allow coloring.
Solution: use `nvim_echo` with colored chunks.
Problem: Sourcing of 'after/plugin' scripts depends on the value of
'loadplugins' option. It is redundant, as it has effect only during
startup, while it is combined with `vim.v.vim_did_enter == 1` (i.e.
"it is after starting up") condition.
Solution: Ignore it.
Problem: `attempt to yield across metamethod/C-call boundary` error when
trying to use `vim.pack.add()`.
Solution: use `pcall()` variant from 'coxpcall' on non-LuaJIT version of
Lua.
Problem: On canceling the update (triggering `WinClosed`), the tab page
will most probably be closed too. Closing some other tab page while the
confirmation buffer is open also changes tab page numbers. We are trying
to close the wrong tab page in both cases.
Solution: save the tab page ID, and attempt to get the tab page number
from the ID when closing the buffer.
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>
