hsnips icon indicating copy to clipboard operation
hsnips copied to clipboard

No feedback when trying to insert tabstops dynamically.

Open yfzhao20 opened this issue 3 years ago • 2 comments

Consider the following snippets:

snippet `abc` "i" iA
$1 111 ``rv=`${t[0]?snip.tabstop(2,"okay"):""}` `` 222
endsnippet

If I write something in $1 tabstop, it is expected to insert a tabstop $2 with text "okay" between 111 and 222.

However it simply inserts string ${2:okay}:

image

Maybe it can only inserts tabstop when I firstly input that. Is there any solution?

Thanks!

yfzhao20 avatar Jan 06 '22 07:01 yfzhao20

I can confirm the issue.

That being said, you don't need the string formatting here (even if the problem still occurs without it):

snippet `abc` "i" iA
$1 111 `` rv=t[0]?snip.tabstop(2,"okay"):"" `` 222
endsnippet

The issue occurs whenever a tabstop is inserted after the first rendering of the snippet result.

I find the behavior of the following interesting as well:

snippet `abc` "i" iA
$1 111 `` rv = !t[0]?snip.tabstop(2,"okay"):"" `` 222
endsnippet

I can't explain why, but the 222 is not introduced back after editing the first placeholder. Peek 2022-01-06 09-50

gruvw avatar Jan 06 '22 08:01 gruvw

Sorry for the delay.

As I mentioned in this comment, the way vscode snippet expansion works only allows us to insert snippets during first expansion, and that was one of the main motivations for migrating to the new syntax for tabstops, as that allows us to show a custom error message when the user tries inserting a tabstop at a later stage.

As such, there is no way to fix this issue per vscode limitations, unless we introduced an entire custom snippet expansion engine (not completely out of the table), but it still is an user experience issue that the error message is not being displayed, so I'll be renaming this issue to reflect that.

draivin avatar Feb 02 '22 17:02 draivin