-
-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use libuv-file-watcher to update loaded snippet-collections. #1033
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
5b2d9aa
to
09a2959
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Looks like it's working for the most common case now 👍 I might have an edge one: I use a |
Ah, that's an interesting case. Did this work correctly before? I'd be surprised if it did, but if it did, we'd have to replicate that :| I'll assume you're by far not the only person to do something like this, so that's definitely something to add to the documentation |
|
Okay so we should be able to do this by substituting our own |
e175dab
to
8e97f27
Compare
7846069
to
4a92b51
Compare
Alright, pretty sure this is done, I'm happy with tests, doc, etc. |
With a quick look around, I'm surprised by the amount of new code in each
Isn't there a way for you to refactor this Collection type to avoid duplication, and only have loader-specific behavior as dedicated impl? |
1863177
to
29bc71f
Compare
So, the first big difference between the (lua and snipmate) and the vscode-loader is that the vscode-collection declares all files that belong to it, and to what filetype, in a manifest (package.json), while the other two consist of a directory-tree, and the filenames determine the filetype. There's more potential with the lua and snipmate-loader, but those also have some differences, for example the handling of |
(What happened to your comment on the unquoted paths? Are they not actually an issue?) |
This is necessary for the key-invalidation in add_snippets, which expects that retrieve_all always returns the same objects.
calling add_edge twice with the same vertices will not connect the vertices twice.
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).
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.
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
8ce5c37
to
3a47a1f
Compare
Currently we register an autocommands on BufWritePost for all files present when
load
is called. This has two undesirable side-effects:This PR is mainly for swapping the autocommand-mechanism for a libuv-based one, but will also include some refactorings of the loaders in general, for example the
cache
, which is a bit hard to grasp.One disadvantage of the libuv-file-watcher is that it does not work for all directories, for example if a file on a nfs-share is edited by one machine, a different machine will not receive events for that edit (at least this is the case for my setup). This means we should probably have some kind of per-collection-fallback (maybe even back to autocommands), and/or a manual command for re-checking (which could also be called periodically..?)
One point I'm not yet sure about is whether snippets whose origin-file is removed should also be removed?
As of now, the mechanism works for the lua-loader, since it's the easiest one :D