Previously, we could not
* add files that were not present when `load/lazy_load` was called to
the collection. This is pretty annoying if one wants to add
project-local snippets, or snippets for a new filetype (ofc).
* load collections whose directory/package.json(c) did not exist when
`load` was called.
This is also an annoyance when creating project-local snippets, since
a re-`load()` is required for the snippets to be picked up.
* pick up on changes to the snippet-files from another neovim-instance
(due to reloading on BufWritePost)
This patch fixes all of these by modularizing the loaders a bit more,
into one component ("Collection") which takes care of all the logic of
loading different files, and another ("fswatchers") which notify the
collections when a file-change is detected. This allows, first of all, a
better design where the first concern can be nullified, and secondly, us
to use libuvs api for file-watching, to implement the last two (if a
potentially non-existing collection should be loaded, we can use libuv
to wait for the collection-root/manifest-file, and create the collection
once that exists).
Another cool addition is the loader-snippet-cache, which makes it so
that the snippet files (for vscode and snipmate) are only loaded once
for all filetypes, and not once for each filetype. That's probably not
noticeable though, except if a collection with many extends/languages
for one json-file is loaded :D
If the same snippet-object is added to multiple filetypes, only the
first filetype receives the source-information.
This is actually done by the vscode-package-loader, so not a
theoretical concern, I guess jump-to-snippet is just not used enough for
this to get noticed.
Since these functions are called by eg. all the loaders, this removes
some potential for cyclic dependencies.
Also add enqueable-operations-wrapper around refresh_notify and
clean_invalidated, to prevent sending multiple updates for the same
filetype in the same "tick"(?), and to remove some overhead that would
result from calling clean_invalidated in quick succession (user doesn't
care if snippets are removed a few milliseconds later, ofc).
Still continues to work with 0.0.5 too, but also support 0.0.6, which,
despite having the same API, is a bit harder to set up (see `util/jsregexp.lua`)
We don't need to use `vim.fn.expand(...)` to get the buffer or file for
the autocmd callbacks. Instead, use `event.buf` or `event.file` directly
from the callback function argument.
See also #1047.
Due to the neovim's issue (https://github.com/neovim/neovim/issues/16416),
using `vim.fn.expand` sometimes throws Keyboard interrupt error when
pressing Ctrl-C (a common alternative to Esc).
This works around the above issue by simply getting the buffer number
from event argument.
