How to make choice node the last/zero node?

[weilbith]

Hey 👋🏾
I have the following issue. If I have a snippet and the last node to jump to is an insert node, I can give it the index 0 as in the docs, and it will be the last jump. If I jumped to it, there are no more jumps available, I stay there and all virtual texts set by ext_opts are gone.
If I know have a choice node as last and it includes for example a text node or an insert node, if I choose the insert node, I can still afterwards jump again, which will be after the last character of the snippet. Until I do this last jump, I'll always see the virtual text.
If I try to give the choice node the index 0 too, it will fail with an error. So this mechanism doesn't work for me.

Here some super random snippets:

local foo = fma'<key> = {\n  <value>\n}', {
  key: i(1, 'key'),
  value: c(2, {
    i(nil, 'value'),
    t('foo'),
})

s('foo', foo)

Having the above snippet makes a final jump to the third line of the snippet after the closing ). But I would like it to stop at the choice node, or rather the chosen choice.
Illustation:

my_key = {
  my_value  -- still virtual text that there is another jump is visible when editing this insert node
} -- cursor lands here after final jump

If I do the following, this works fine:

local foo = fma('<key> = {\n  <value>\n}', {
  key: i(1, 'key'),
  value: i(0, 'value'),
})

s('foo', foo)

Illustration:

my_key = {
  my_value  --  no virtual text anymore, cursor stays here, no jump remaining
}

---

EDIT:
While I was thinking about it again, I kinda see that for a choice node it is a little complicated. Because until you jumped again, you are still in the choice node and the choice isn't over. But I feel like there must be something to resolve it. Could it be like as soon as the user has interacted with a choice node, the choice becomes visited. And if you chanted your mind, you could possible use the jump back keymap?

EDIT 2:
Same issue with dynamic nodes that can't be set as the final/zero node.

[L3MON4D3]

Hi! :)
Oh, yeah that's a tough one. You correctly identify the issue with just making the choiceNode last in your first edit, I haven't been able to find a good, general workaround for it :/
Your suggested behaviour of leaving upon changing something can be implemented via callbacks with change_choice (has to be passed to the surrounding snippet/snippetNode, with the jump-index of the choiceNode) (I think you'll want to vim.schedule a jump forward, otherwise the set_choice-routine would undo your jump immediately... not a clean solution unfortunately :/)
I think making use of events gives some new possibilities, and is worth looking into for this.

[weilbith]

Hmm. But a scheduled jump forward would only make it worse, right? I actually don't want to jump. The problem is more that while a choice of a choice node is active, the choice node remains active too. So when I'm editing value, both nodes are active at the same time.

A workaround would be to add an additional insert node with index zero after the choice node. Then at least the cursor position is correct. But it is kinda annoying. Because I reached the end of the snippet and I want the virtual text to disappear too. Typical example a snippet for creating a method and at the end I'm in the body of the method, snippet done and over. I'll continue programming on the body now without being "annoyed" by the still active snippet. Also highlights of the active node still apply. I also want to avoid to trigger nested snippets now because that would make the visuals only worse. 🙈

Could I write a callback that disabled the choice node and only keeps the insert node active or similar? :thinking_face:

Would it be possible to say all key inserts except some (used to switch choice node) lead to exit the choice node? Or would that also leave the choice its child node because it is nested?

[L3MON4D3]

Oh, true, that wouldn't be a good solution in general, I was focusing too much on "change-to-textNode-and-finish-snippet" 😅

Could you show some videos of the exact behaviour? I'm having a hard time really understanding the problem because I don't have that much virtual text, only a few ●.
But as far as I can gather, one way to solve the problem would be activating highlights only for the innermost active node, like

choice -> {
    choice -> {
        i(nil, "t1"),
        i(nil, "t2")
    },
    i(nil, "touter")
}

and in t1 only its highlight is active, not that of either of the surrounding choiceNodes? And as soon as a new snippet is expanded inside it, the virtual text from t1 disappears, and the new snippet's i(1) is active

[weilbith]

I'll do a video when I'm on my PC again tomorrow (can you recommend a good/simple terminal recording tool?). 👍

If I get your proposal right it sounds pretty good to me. 🙂

Little other topic: how hard would be to allow using a function to define the virtual text of a node instead of a static string? I would love to show something like 1/3, 2/3 for a choice node (current choice index / total choice options). 😁😅

[L3MON4D3]

can you recommend a good/simple terminal recording tool?

Oh, any screen-recorder will do (I use wf-recorder since I'm on wayland), I find stuff like asciinema a bit cumbersome for github (as opposed to mp4, which are directly embedded)

I would love to show something like 1/3, 2/3 for a choice node (current choice index / total choice options).

Oh that's cool.
I think it's possible to write a wrapper which acts like choiceNode, but wraps the passed choices in a snippetNode to provide that highlight (would be a nice addition to luasnip.extras if you end up writing something like it)

I definitely agree that using a function to provide highlight would be pretty cool, I'd have to take a good look at that code again to measure its feasibility (but I recall having discouraged stuff like this in the past, I think it would be evaluated very often/end up being pretty complex).
One way to implement it right now is using dynamicNode to attach different highlights to its generated snippetNode, there might be an example for this/sth. similar in the issues/DOC.md's ext_opts-section