- create poc
- decide on API
- make it work for my own config
- support for commits and tags
- support for running commands after clone
- support tables with options in from (+tests)
- write initial setup routine
- update images to have git configured properly (name email)
- use submodule instead of clone
- clone plugins into opt and call packadd in .from
- display some ui during clone
- create basic api for lazy-loading on events
- add example using kickstart as a base
- write tests for to_handle
- add commands
- add way for examples to use cached plugins to speed up debugging
- watcher for example runner
- let it sit for a few days
- do a code review, refactor
- create basic api for lazy-loading on keypresses
- add keymap tracker to prevent duplicate keymaps
- provide example for lazy-loading
- on events
- on keypress
- add docs/help
- write proper readme
- include version number in plugin-path if set
-
automated tests using the examples?
-
support for a
dependency
property?I usually found that order of imports is much more intuitive. However including it would make the migration path from something like lazy a bit easier, since it would incloud less changes.
and tasks that turned out not work
- A fancy UI
Instead of a UI, make it easy to run the appropriate git commands that will give similar results and has far greater value
- [-] vim.g.baggage_* to vim.g.baggage.* for lsp? not worth it, because one would have to check if vim.g.baggage exists in the install script