Expose stable `store_selection()` in API

[hinell]

store_selection is commonly used in custom keybindings to store selection before calling luasnip.expand()

I request to expose it via main api and maintain across versions. Thanks.

See related comments:

• https://github.com/L3MON4D3/LuaSnip/pull/1013#issuecomment-1746571683

[L3MON4D3]

I understand that a proper lua-api would be great, but afaict the only use case of retrieving the current visual selection is cutting from visual mode via a keybindig. Do you have examples where using the exposed rhs (as proposed in #1013) of the mapping is not sufficient?

[L3MON4D3]

As a sidenote, I'd love to have a simple lua-api function that uses nvim_buf_get_text and nvin_buf_set_text to cut the current selection, but afaict this is very complicated to implement correctly while taking care of all the options that affect selection. This is the main reason why I'd like to only expose the rhs of a mapping for now, once neovim has an API for cutting the selected region we can upgrade that.

[bew]

One use-case for an exposed store_selection could be to support the case mentioned in doc:

TM_SELECTED_TEXT is designed to be compatible with VSCode's behavior, which can be counterintuitive when the snippet can be expanded at places other than the point where selection started (or when doing transformations on selected text)

Where we could use the function to store selected text (don't even need to cut it), move around and use a snippet that use the last selection for something.

[L3MON4D3]

I don't quite get what you mean, not having to cut the text could also be achieved with separate rhs's/a function that returns the appropriate one

[hinell]

@bew The use case is obvious. I even made a demo in related PR #1026 that utilizes snippet with ${TM_SELECTION} .

@L3MON4D3 store_selection() is used to update ${TM_SELECTION} variable to be used inside snippets. It's quicker and more handy just to call store_selection() before expansion than using registers for instance.

but afaict this is very complicated to implement correctly

It's already done in #1026. Your PR #1013 in constract, has major flaws. I've pointed out them already.

[L3MON4D3]

The use case is obvious.

Not to me. In the video you use a mapping, for which you don't necessarily need a pure lua function, the rhs suffices.

It's already done in https://github.com/L3MON4D3/LuaSnip/pull/1026

That implementation does not use nvim_buf_get/set_text, but uses the same underlying mechanism as #1013. Please read my comments more closely.

[hinell]

for which you don't necessarily need a pure lua

We do and there are a use cases like custom bindings that may modify text to be stored before call to require("luasnip.util.util").store_selection() is made. I don't get how you don't get this point.

That implementation does not use nvim_buf_get/set_text,

Nether of PRs use that api.

I feel like continuing this discussion is more like a waste of time that forces us to maintain a separate fork for this feature. Ridiculous. At least two people said that feature is needed.

[L3MON4D3]

We do and there are a use cases like custom bindings

Alright, then show me one please.

Nether of PRs use that api.

Yes I'm aware, that's why I said I would love to have that.

maintain a separate fork for this feature.

You are very free to create and maintain a fork if you don't like my decisions.

[hinell]

I think I'm clear that it's used in custom keybindings. I see no reason to elaborate given time I've wasted on explaning obvious things elsewhere. Cheers.

[hinell]

Still relevant as of 2025 lol.