[Feature Request] Get Position of Destination if Jumpable

[Bekaboo]

First of all thank you for this awesome plugin! It is fast and super powerful, but there's one thing that I'm struggling with to get a smoother experience -- I use a custom function to use <Tab> to jump out of parenthesis and brackets, but I always mess it up with luasnip's jump functionality.

So I want to ask if it is possible to get the destination position of a luasnip jump? If so I can get the destination position of the jump from luasnip then I can compare the destination of the jump performed by luasnip and that of the jump of my custom function then always choose the one with the smaller cursor displacement.

[L3MON4D3]

Hi!
Cool idea, that should be possible to implement. Will take a while though 😅

[Bekaboo]

Hi! Cool idea, that should be possible to implement. Will take a while though 😅

Thank you! It will be even better if we can get the destination position of a back jump (<S-Tab>) through luasnip api.

[Bekaboo]

Hello! I would like know if LuaSnip is going to implement the feature in the foreseeable future? Thanks! 😄

[L3MON4D3]

I have some time today, I'll look into it :)

[Bekaboo]

Thank you! I've looked through the code base several times trying to figure out how LuaSnip moves the cursor to the right position. I did find some nvim_win_set_cursor but the whole logic is too complicated for me 🥲. Hoping that LuaSnip will finally support this feature and thanks for your great work!

[L3MON4D3]

I've looked through the code base several times trying to figure out how LuaSnip moves the cursor to the right position. I did find some nvim_win_set_cursor but the whole logic is too complicated for me 

It's pretty hard to get into the "core-logic", especially because there are sooooo many functions in each node 😅 I'll have to write some documentation on what each does sometime

Anyways, I did a PR, which should work (would be cool if you could check it out and see if everything is going smoothly, I did not test it completely yet 😅): #740

[Bekaboo]

I'm testing this out and it works pretty well so far. The return value of jump_desitination() is informative (in some case the size of the table is over 3000 lines) and I'm still managing to find the index of the node in the return value.

[L3MON4D3]

Ha, yeah informative is putting it lightly xD
It's the node that is the target of the next jump, including references to all the other nodes in the snippet, so yup, there's a lot

Can you find all the data you need?

[Bekaboo]

Can you find all the data you need?

No.. I haven't found out yet. I'm trying to find the absolute/relative position (either 0-indexed or 1-indexed) of the next node. Ideally the location data should be like the parameters passing to nvim_win_set_cursor.

I'm looking into the field absolute_position but it seems nowhere like the position I'm jumping to (it is always 2 or 4 in my case?). I also investigated dependencies_dict, where some node objects reside, but nothing fruitful either.

[L3MON4D3]

Oh, I added that too in the PR, take a look at the second commit.
absolute_position is the "node-address" inside the snippet, see absolute_indexer in DOC.md

[Bekaboo]

Thank you so much! My bad, I didn't realize that I can use get_buf_position to get the position of a node.

Now I'm able to get the destination with:

local next_node = luasnip.jump_destination(1)
local pos = next_node:get_buf_position()

[Bekaboo]

Hi! I've tested the APIs these few days and I find that in some cases jump_destination(-1) will never return and block nvim, here is a demo (the first snippet works as expected but in the second try I triggered this bug):

simplescreenrecorder-2023-01-25_19.54.18.mp4

You can see my mapping for <S-Tab> in the pane on the right.
However, this case does not happen to jump_destination(1)

[L3MON4D3]

Oooh, I think the issue is that not changing any state may lead to this endless loop. Could you share the snippet?

[L3MON4D3]

nvm, I found the error :D
It should work with the latest changes

[Bekaboo]

Thanks, it now works flawlessly!