[TxMt] Re: possible format strings bug

[Allan Odgaard]

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.