Repository navigation
Conversation
maparg() reads the mode `!` as normal mode, so the proxy of a key in mode `!` or `!a` looked unmapped: the first press was swallowed, and the proxy stayed when the plugin loaded another way. Both lookups now go through one helper that asks for insert mode.
After a declined install `:ZPack! build` reported the plugin as not registered, then ran its build with a nil plugin and counted it.
`:ZPack update <name>` and `:ZPack restore <name>` checked the name against the tab-completion list, which leaves out plugins `cond` keeps unloaded, and answered "not found in spec" for one the bulk update covers. They now ask the registry.
`:ZPack reload` only looked at `package.loaded` keys under the plugin's `main`, so `telescope._extensions.x` and other second namespaces stayed stale. As in lazy.nvim, every module with a file under the plugin's `lua/` is dropped.
`:ZPack reload` of a pending lazy plugin ran its teardown hook, which could pull the plugin in through a `require` and configure it twice. As in lazy.nvim, the hook runs only for a loaded plugin.
A plugin whose `lua/` holds one top-level module not named like it, as none-ls.nvim's `null-ls`, got a "Could not determine main module" warning and no `setup()`. lazy.nvim's get_main falls back to that module, so LazyVim's none-ls extra relies on it.
setup() runs once, and state.lua creates LazyBuildPack and DeletePack cleared; their only writers run after these lines.
register_all hands them over sorted with the same comparator, a total order, and nothing in between changes a priority or an import order.
entry_to_info spelled the mid-install shape itself, which left derive_status's own "installing" branch unreachable.
The KeySpec reference said `(function, required)`, against the type, the code and `:h zpack-Spec.keys`.
It listed a `rev` field the API doesn't return, and lacked the "installing" status and its nil `path`.
The vimdoc's Spec.build gave only string and function, and spec.md said shell builds run via $SHELL, which hooks.lua avoids on purpose.
The reload and dev passages presented `dev = true` plus `:ZPack reload` as the loop for iterating on a local checkout. `vim.pack` clones the checkout into its data dir, so an edit reaches Neovim only after a commit and `:ZPack update <name>`.
…efore `config` `:ZPack update` and `:ZPack delete` complete the registered names, as the restore entry already says, not every installed plugin. `plugin.main` is resolved before `config` is called and is nil inside `opts` functions.
Several entries in the help file and the migration notes had grown into single paragraphs listing every edge case. Split them into a short description followed by lists, lead each command and field with what it does, and say "as in lazy.nvim" in a sentence where a bare tag stood. No behaviour is described differently.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes from an audit of the whole plugin, plus dead-code removal and a docs pass.
Fixes
!or!anow runs its rhs on the first press, and its proxy is released when the plugin loads another way.:ZPack! buildno longer runs a build for a plugin whose install was declined.:ZPack update <name>and:ZPack restore <name>accept acond = falseplugin, as the bulk forms already did.:ZPack reloaddrops every loaded module under the plugin'slua/, not only those in itsmainnamespace, and no longer runsdeactivatefor a plugin that never loaded.lua/holds exactly one top-level module uses it asmain, as in lazy.nvim (none-ls.nvim, alpha-nvim).Refactors
No behaviour change: two clears of always-empty augroups, a second sort of the startup packs, a branch that assigned nil into a fresh table, and a duplicated
PluginInfoconstruction are removed.Docs
[2]is optional and can be a string;buildtakes a list orfalse; adev = truecheckout is cloned, not used in place;plugin.mainis set beforeconfig.doc/zpack.txtand the migration notes are split into short descriptions and lists.Testing
zb checkagainst the base: no lazy flips, structural or opts differences; one perf row (trig150on 0.12) is flagged identically onmain.