Is it possible to store "user's custom metadata" within a snippet, and get that data after the snippet expands?

[ziontee113]

Hi! Sorry for the convoluted title 😅 , but I'm working on a Nvim plugin to quickly create & edit LuaSnip snippets.

One problem I'm running into is how to identify which already-existing snippet the user wants to edit.
The solution I'm thinking of is something like:

• When creating the snippet, add an opt that records the exact time the snippet was created.
• When the snippet is triggered, a LAST_TRIGGERED_SNIPPET_CREATION_TIME global variable is updated.
• With that global variable, I can read the snippet files and search for that exact snippet to edit.

Is there a way in LuaSnip that can solve this problem? I don't really want to pollute the desc or docstring opts tho 🤔

[L3MON4D3]

Uhh, yeah there is actually a PR for something like this, see #719.
Although the intention there is different, and the scope would have to be increased a bit, I think it would be cool to have per-snippet metadata.

What you can do right now, is identify snippets based on their id (snippet.id) and associate that with any data you like.

Besides that, I don't quite understand how the time a snippet was created at helps with identifying it, wouldn't it make more sense to where it is defined?

[ziontee113]

Besides that, I don't quite understand how the time a snippet was created at helps with identifying it, wouldn't it make more sense to where it is defined?

Well, you'll need to find the start row to end row of that file anyway, so I thought about using ripgrep to grep for that date. Since almost always that specific time will be unique.

What you can do right now, is identify snippets based on their id (snippet.id) and associate that with any data you like.

If I can get which file + the row start - row end of that snippet with snippet.id then it's even better. But I'm not sure I can do that.. 🤔
I'm planning to change the snippet at the actual file, I'm not planning to use any databases tho 🤔

[L3MON4D3]

Ahh, grepping for the date is an interesting approach, but it does seem prone to bugs :D

If I can get which file + the row start - row end of that snippet with snippet.id then it's even better. But I'm not sure I can do that..

Oh, no that is not as easy. To begin with, the snippet might be expanded multiple times, so that should be handled.
There is luasnip.session.current_nodes[bufnr] which stores the currently active node of a snippet, you can do node.parent.snippet to get the snippet, and then snippet.mark:pos_begin_end() to get some info on its position in the buffer (node.mark:pos_begin_end() can be used on any visible node IIRC, but don't rely on it, we'll have to put a proper API in its place sometime 😅)

[ziontee113]

Come to think of it, I could just use docstring to store the metadata. Getting the last triggered snippet is already possible with session.last_expand_snip. It's just might look ugly and noisy when seeing docstrings...

[ziontee113]

I'm planning to use something like:

cs({
    trigger = {
        trig = "hello",
        metadata = {
            created_at = "12/12/2022 19:00",
        }
    },
    nodes = fmt(
        [=[
hello {}
]=],
        {
            i(1, "world"),
        }
    ),
})

[L3MON4D3]

I think designing this such that the snippet itself does not have to be aware of the metadata is a good idea, so implementation-wise something like

local snip = cs(...)
luasnip.set_metadata(snip, {created_at = "..."})

But I can see that this is not as ergonomic...

[leiserfg]

There is a PR in progress for adding custom metadata to snippets #719 maybe you can have a look and bring your opinions/ideas there.

[ziontee113]

Thank you @leiserfg @L3MON4D3 for the direction to the PR. I'm thinking of a different approach, please correct me if I'm wrong:

• As of right now, LuaSnip only "store" the the keys it needs (valid keys) in the trigger and opts table.
• My suggestion would be to qualify "metadata" or "custom-metadata" key as valid, so when the user have a snippet variable, for example from using session.last_expand_snip, they have that "metadata" field as they want.
• This "metadata" key / field is totally optional, only used by who needs it, won't be intrusive and easy to implement. (please correct me if I'm wrong).

Another approach would be in the user's luasnip.config.set_config, user can define a table of "custom metadata keys" so those keys will become valid to use.

[L3MON4D3]

Well, this isn't that different from what we're going to eventually do in the PR, just with a bit more granularity: instead of per-snippet (what you want), it's per-add_snippets-call. Since both will have to coexist, they should be pretty similar, with the only difference being their granularity.

I really don't want to have snippet.metadata just accessible like that since

• we'd have to do some trickery to not copy it when the snippet is copied
  (copying it is undesirable since it stays identical)
• giving access to any api via just raw table-access (which is how I understand your proposal, correct me if I'm wrong) has proved to be pretty hard to manage if we want to change the implementation.
• we could implement the whole metadata-stuff in session.snippet_collection, and the snippets don't even have to know about it, which is very attractive

Maybe to make it a bit more comfortable, we could provide a function which
behaves more like you imagine, for example

local function snip_with_metadata(snip, metadata)
	ls.set_metadata(snip, metadata)
	return snip
end

snip_with_metadata(cs(...), {<metadata>})

[ziontee113]

Thank you for the insights. I'll wait for the PR to complete then 😄. In the mean time, I'll use docstring temporarily.

we'd have to do some trickery to not copy it when the snippet is copied (copying it is undesirable since it stays identical)

Do you mean copying metadata is wasteful since that data will be identical between copies? I admire your dedication to efficiency.

[L3MON4D3]

Nice :D
Yeah, exactly, and it feels a bit wrong to just throw the metadata into the snippet itself when it could be handled separately

[ziontee113]

Oh, no that is not as easy. To begin with, the snippet might be expanded multiple times, so that should be handled.
There is luasnip.session.current_nodes[bufnr] which stores the currently active node of a snippet, you can do node.parent.snippet to get the snippet, and then snippet.mark:pos_begin_end() to get some info on its position in the buffer (node.mark:pos_begin_end() can be used on any visible node IIRC, but don't rely on it, we'll have to put a proper API in its place sometime sweat_smile)

Sorry I missed this part. What I meant was to get the row start - end at the snippet file itself (where it was created, not the expanded snippet). So I can rip that part out and replace with the newly edited snippet (I'm still figuring out a way for the user to edit snippets on the fly, without having to "physically" go to where the snippet was created / defined 😄 ).

Ahh, grepping for the date is an interesting approach, but it does seem prone to bugs :D

Yup, I really don't know a better way to approach this.
The current plan is to:
- Grep for that date --> have the exact file name.
- Use Treesitter to parse that whole file, use custom query to get the snippet with that "created_at" field.

• With the upcoming metadata PR, get the file name
• Use Treesitter to parse the file, then use custom query to extract the snippet with that "created_at" field.
• With the range from that parsed Treesitter node, get the start - end rows --> Replace those rows with the newly edited snippet.

Having to manually go to the snippet file, edit it, then jump back to the work you're working on is disruptive, which I'm finding a way to solve.

[L3MON4D3]

Ahhhh alright, that's cool.
Using treesitter seems like the correct approach👍👍