On 6 Apr 2014, at 1:10, Matt Neuburg wrote:
[…] I'm not saying you should change anything! The problem is solved, and one wouldn't want to risk breakage.
The change I did should not cause breakage.
Variables are still inherited, but if a deeper regexp captures/creates $1-$n then these variables are excluded from potentially being inherited. In most cases, the deeper regexp will overwrite the values of these variables, resulting in the same effect, but when using conditional captures (like your example) there is a possibility for the deeper regexp to not overwrite the variable, which is the case in which we want to disable inheriting the parent’s value.
[…] One last note: I am still mystified by what happens if we _remove_ the question mark after the parentheses in the first half of the replace expression:
${1/(hey)/${1:?howdy:scram}/}
In that case, I can in no circumstances get "scram" to appear. I don't understand why not. The search for "(hey)" has failed, but $1 still has meaning, so I expect to see either "howdy" or "scram". I see _neither_.
The regexp /(hey)/ requires matching “hey” in the text. If “hey” is not found in the text, it will not match, and no replacement will be done (so TextMate never looks at the format string you provided for this replacement).
Contrast that to /(hey)?/. By adding ‘?’ after ‘(hey)’ we make that part of the regexp optional. This means the regexp will try to match “hey” (and put that in $1), but if there is no “hey” in the text, the regexp will still match (as we made this part optional), though nothing is captured in $1.