-
-
Notifications
You must be signed in to change notification settings - Fork 248
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
add meta data for each add_snippets
call
#719
Conversation
It seems that the CI removed my additions to the |
Ah, yeah add doc to |
fixed it |
Nice 👍 |
@@ -24,6 +24,7 @@ local defaults = { | |||
region_check_events = "User None", | |||
delete_check_events = "User None", | |||
store_selection_keys = nil, -- Supossed to be the same as the expand shortcut | |||
store_meta_data = false, -- For each snippet, eg. source path. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd like this to be a table, which can accept keys to determine what is stored. Most capable would be just a function which receives all available data and creates the metadata for the snippet, but I think this is overdoing it, since we probably don't need much flexibility there.
Still, making this a table would somewhat future-proof it, like
metadata = {sourcefile=true, line=true, custom = somefn}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using a subtable is good idea. I don't understand your reasoning about the function but it makes sense to do this properly in case we come up with more use cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks!
My idea with the function was to allow complete customization of what is put into the metadata, essentially by calling a function like
function loader_metadata(filename, line)
return {source=filename, source_line = line}
end
in the loaders.
Since there isn't this much customization possible (I think), letting the user set some keys for what exactly should be stored in the metadata-table seems like a more straightforward, and easier to use simplification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ill try to making it into a func and see how it feels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now, this is the only thing left to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would one get the source line of the snippet in this function? Is there something builtin to luasnip already?
Oh, that's very hard to do for lua and vscode, I used it because I wanted an example for why more flexibility might be good.
I think we should not determine all lines up-front (except if it's trivial, like in the snipmate-loader), since only a tiny subset of this information will be useful, and it should, I think, be calculated on-demand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not very hard, non-trivial
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the location for where the meta data loader should be called is within the
session.snippets_colletion
right, so we need tolocal session = require("luasnip.session")
and then pass alongsnippets
andopts
tostore_meta_data()
.
I had in mind that add_snippets
receives the complete metadata (which may be nil), and we make the config-option specific to the loaders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not very hard, non-trivial
Aight, for now my feed keys thingy works good nuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! heuristics like that should do it for 99%
* upstream/master: Auto generate docs Auto generate docs docs(extras): add Snippet List feat(extras): added open_snippet_list
opts.scope allows one to either retrieve: 1. buf snips 2. snips by list of requested filetypes 3. all possible snips if scope == "everything" opts.include_autosnippets
Now you can either:
|
Oh i realise that I merged master instead of rebasing. Ill have to look into how I can undo this later. |
i created a base for using a user function when loading meta data. check it out and tell me what you think. |
Also feel free (not important...) to try my picker that I linked to under the issue discussion. it shows you how I use all of the features in the |
I think we can use |
I'll take a look at the other changes later😅 |
Aight no stress! |
Cool yeah im down for whatever. I'll wait untill you've had a closer look and then I modify it accordingly. |
@@ -113,6 +113,30 @@ local function match(index, _match, _then, _else) | |||
return F(func, index) | |||
end | |||
|
|||
local function jump_to_snip(snip) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this deserves its own module, then we can cleanly provide different heuristics for finding the correct snippet (after making that configurable ofc :D)
For example, finding in snipmate/lua/vscode could be made more precise by writing it specifically for that type of snippet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok. i'll move this into its own module.
@@ -63,24 +63,66 @@ local function default_snip_info(snip) | |||
} | |||
end | |||
|
|||
local function available(snip_info) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay afaict this can also be achieved with either the old available (scope=buf) or get_snippets (everything else). Even though this design is nice, separate functions are backward compatible, so I think we should stick with that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
quick note: my addition should be backwards compatible.
I'll get back with another reply later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allright, so I think I understand what you mean but could you tell me a bit more specifically what you'd like me to do. Is my modification worth keeping in a modified state or should we scrap it completely?
My idea was that it made sense to put the logic in available so that one could filter all possible combinations via snip_info but I am also down with splitting it up somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, of course it is backward compatible 🤦
What I don't like about this is that there's no good reason for snip_info
to not be a part of opts
, except staying backward compatible.
I think we'll have to scrap it :/
An alternative would be to expose it in addition to available
(and implement available
using it), but all of its functionality can be covered better by get_snippets
(since get_snippets can access the implementation of snippet_collection
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative would be to expose it in addition to available (and implement available using it), but all of its functionality can be covered better by get_snippets (since get_snippets can access the implementation of snippet_collection)
Yeah this makes sense. I'll try to add a new successor func that only uses the opts
param. I'm thinking about calling it filter_snippets(opts)
or retrieve_snippets(opts)
.
local snippets_meta_data = {} | ||
local snip_id_to_meta_map = {} | ||
|
||
local function initialize_snippet_meta_data(opts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I think this mechanism is good, but we need to split it up a bit:
config
generates a function which, given a filename produces the metadata that shall be added to snippets loaded by one of the loaders. We should not pass the filename directly, but wrap it in a table like{filename=<the filename>}
, since we can then add more arguments and the function will stay comfortable to use (no need to write a handler likefunction(_, _, _, theOneArgINeed) ... end
)- this function is used in loaders to generate the metadata for the snippets (no ifs or something like that, we can just call the function. This is flexible enough to probably not require any changes, except if new parameters are added)
add_snippets
receivesmetadata
-table, which is associated with the snippets added in this call, unconditionally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I have to ponder your reply and come back later with a revised version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to it :D
If you have any questions or other ideas, go ahead, I'd love to find something better (especially the association of snippet with its metadata is a bit annoying, since we have to do that id-redirection. Can't think of a better way though :/)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, yeah I cant really come up with something better either atm.
Let's optimize it later and I'll stick to the id mapping for now.
d629fc2
to
74d80e5
Compare
Hey! Are you still interested in working on this? No worries if not, I'd be up for getting this done |
Was feeling a bit too motivated the last few days, couldn't resist doing some work on this 😅 |
Hey mate!! editDude, you added the feature where one can jump to the source from within an opened snippet - that is pretty damn cool. |
Phuh, that's rough😅
👍👍
Take your time, I don't have much to do right now, so plenty of opportunity to work on this :)
Yeah! Really happy that worked out so well :D |
Has it already improved your workflow? |
Nah xD |
Reminds me that after all the work in LuaSnip, I have just like 5 custom snippets 😄 |
😆😆 |
lol |
I've finally merged #826, closing this as well. |
available()
to be a bit more versatile.jump_to_snip()
under extras