Sublime Forum

Question for duplicate placeholder default values for the same snippet field

#1

Ok, these might be a little bit of a weird question and unfortunately many of the details are vague because they come from experiments I preformed several months ago, so I probably should apologize for that in advance, but as I find myself confused about this technicality regarding snippets, I felt like asking just in case anyone has similar experience.

In particular after playing around a little bit I remember noticing that sublime did not like when a placeholder field had its default value defined twice or more, so for example

${1:data} = $1 + $2

was okay whereas

${1:data} = ${1:data} + $2

would not be inserted. Of course this usually is not a problem, but can be in some rare cases,eg if snippets were generated by a script and care had not been taken.FWIW I also remember noticing these only for mirrored fields you can tab through, so placeholders for external parameters caused no problem even if they were different,eg

${PARAMETER:data} = ${PARAMETER: something else} + $1

With that in mind, I considered writing some code to handle this issue by preprocessing such snippets before passing them down to insert_snippet command, but due to lack of time and other priorities I did not pursue it. Now that I finally got around to it, to my surprise I can no longer reproduce this issue. Snippets like the one above ${1:data} = ${1:data} + $2 are inserted without any problem, which is great but leaves me wondering whether:

  • During my experimentation, I made some mistake and stuck with the wrong conclusion, in which case the extra code is redundant

  • My conclusions were correct and this “technicality” existed in previous versions but not in the latest one, so the extra code might be needed after all

Part of the reason why I considered the second scenario possible is that I cannot really remember if my sublime was upgraded to 3211 shortly before or after those experiments and it did not occur to me to check the sublime version at the time. Now as I couldn’t find anything relevant in the change log, it is very likely that I am dealing with the first case, but not really being sure I felt like it might be worth asking here, just in case someone has come across this In older versions of sublime or could confirm/disprove either claim.

0 Likes
#2

I didn’t pursue this too extensively, but I have every publicly released build of ST going all the way back to build 3006 (circa January 2013) and this snippet expands there the same as it does in build 3211 and 4079.

From that I would guess that the first case is more likely than the second, unless there was a bug in one build that was fixed in the next, though normally that would appear in the Changelog as a reression that was fixed.

That said, snippet content like this doesn’t work as you might expect:

${1:data} = ${1:other} + $2

The default value for a field is always the first one seen, so even though the second one has a default value of other, it still expands out as data; perhaps you were seeing something like that?

2 Likes
#3

many thanks @OdatNurd for taking a look at this ! based on your results I also tend to believe it was almost certainly my error, though not sure which specific. what you’re suggesting as an explanation sounds plausible/reasonable but I remember giving it a try with both queries of the form

${1:data} = ${1:data} + $2

and

${1:data} = ${1:other} + $2

and the result in both cases was the snippet not been inserted at all, so I do not think it is likely that was the cause of the problem. Another possibility might be that there used to be some subtle error elsewhere in my stack (snippets are inserted from an external process via sublime commandline interface) or that I misused it somehow. Whatever the case, it’s good to know that this is most likely a personal rather than a systematic error!

PS: at the very least something does appear to be consistent between my experiment and what I’m currently seeing:D

In particular, if we assign two different default values to parameters like

${PARAMETER:data} = ${PARAMETER: something} + $1

and pass no value for PARAMETER each one will expand to each own default value dear, so the first one to data and the second one to something. This was/is in contrast with what happens when instead of a parameter we have a field like the snippet you posted

${1:data} = ${1:other} + $2

where the second placeholder indeed expands to data.

0 Likes
#4

I think this is expected (or at least logical) behaviour in this case.

Regular variables expand out either to the appropriate value, to the specified default, or to nothing at all (depending on the situation). In that case each of the expansions happens essentially one after the other, where each variable expands in turn to the appropriate value.

On the other hand snippet fields represent places where there will be a caret and the ability to enter text. When a field is jumped to, it’s value is selected so that typing can replace the placeholder with the appropriate text, but every mirrored copy of the field also gets a cursor and edits simultaneously

So, in that case the expectation is that you intend to enter the same text in multiple places all at once, so all fields should always be the same value while the snippet is processing.

Here if you intended the two values to potentially be different you’d use a different field for it so that it’s possible to adjust them independently.

Similarly, if you use a regex to modify a field expansion on the fly, it’s represented in the buffer as the snippet expands, but it doesn’t gain a selection or a caret because the inference is that it’s value comes from elsewhere:

${1:data} = ${1/./\u$0/g} + $2
2 Likes