Hi.
http://pastie.textmate.org/40039 is parsed wrong by my textmate installation. I'm running the latest version from svn. Seems to have a problem with $<delim> under qr. works fine with m//.
* Marcus Ramberg marcus.ramberg@gmail.com [2007-02-13 14:25]:
http://pastie.textmate.org/40039 is parsed wrong by my textmate installation. I'm running the latest version from svn. Seems to have a problem with $<delim> under qr. works fine with m//.
Oh, nasty. The $ is matching as the start of a variable name. I'm not sure how to fix that. In the mean time, you can use a delimiter that doesn't match as a variable. qr{} works.
On 14. Feb 2007, at 22:03, Grant Hollingworth wrote:
- Marcus Ramberg marcus.ramberg@gmail.com [2007-02-13 14:25]:
http://pastie.textmate.org/40039 is parsed wrong by my textmate installation. I'm running the latest version from svn. Seems to have a problem with $<delim> under qr. works fine with m//.
Oh, nasty. The $ is matching as the start of a variable name. I'm not sure how to fix that. In the mean time, you can use a delimiter that doesn't match as a variable. qr{} works.
I assume variables are allowed in regexps?
So likely Perl distinguish between end-of-line-$ and start-of- variable-$ by what follows the character? We could make the regexp variable rule do the same in TM.
On 15 Feb 2007, at 04:36, Allan Odgaard wrote:
- Marcus Ramberg marcus.ramberg@gmail.com [2007-02-13 14:25]:
http://pastie.textmate.org/40039 is parsed wrong by my textmate installation. I'm running the latest version from svn. Seems to have a problem with $<delim> under qr. works fine with m//.
Oh, nasty. The $ is matching as the start of a variable name. I'm not sure how to fix that. In the mean time, you can use a delimiter that doesn't match as a variable. qr{} works.
I assume variables are allowed in regexps?
So likely Perl distinguish between end-of-line-$ and start-of- variable-$ by what follows the character? We could make the regexp variable rule do the same in TM.
You can also use $ as a regex delimiter
qr$ All?an $
in that case $ isn't part of the RE.
* Allan Odgaard throw-away-1@macromates.com [2007-02-14 21:37]:
I assume variables are allowed in regexps?
So likely Perl distinguish between end-of-line-$ and start-of- variable-$ by what follows the character? We could make the regexp variable rule do the same in TM.
Right. The problem is that Perl allows almost any punctuation character to be a regexp delimiter. For paired delimiters we specify the end character explicitly:
name = 'string.regexp.compile.nested_braces.perl'; begin = '(qr)\s*{'; end = '}'; captures = { 0 = { name = 'punctuation.definition.string.perl'; }; 1 = { name = 'support.function.perl'; }; }; patterns = ( { include = '#escaped_char'; }, { include = '#variable'; }, { include = '#nested_braces_interpolated'; }, ); Here, including the variable pattern works properly.
For single-character delimiters, we define the end character as \2 from the match:
name = 'string.regexp.compile.simple-delimiter.perl'; begin = "(qr)\s*([^\s\w'{[(<])"; end = '\2'; captures = { 0 = { name = 'punctuation.definition.string.perl'; }; 1 = { name = 'support.function.perl'; }; }; patterns = ( { include = '#escaped_char'; }, { include = '#variable'; }, { include = '#nested_parens_interpolated'; }, );
Here, the variable pattern seems to have precedence over \2.
On 15. Feb 2007, at 18:01, Grant Hollingworth wrote:
- Allan Odgaard throw-away-1@macromates.com [2007-02-14 21:37]:
I assume variables are allowed in regexps?
So likely Perl distinguish between end-of-line-$ and start-of- variable-$ by what follows the character? We could make the regexp variable rule do the same in TM.
Right. The problem is that Perl allows almost any punctuation character to be a regexp delimiter. For paired delimiters we specify the end character explicitly: [...] Here, the variable pattern seems to have precedence over \2.
Actually not, i.e. the following works fine:
my $foo = qr$allan$;
What fails is using $ in a regexp where it looks like a variable but is actually not.
Normally in Perl $/ is a predefined variable, which means we can do the following (which TextMate handles correctly, and Perl as well :) ):
my $foo = qr!test $/!;
But now let’s use / as delimiter instead:
my $foo = qr/test $//;
This is ambiguous. TextMate chooses to still see $/ as the predefined variable, and thus considers the entire line as well-formed, where Perl switches interpretation of $ into the end-of-line anchor, which makes it choke at the last / (since the second last / terminates the regexp).
* Allan Odgaard throw-away-1@macromates.com [2007-02-15 10:47]:
Actually not, i.e. the following works fine:
my $foo = qr$allan$;
What fails is using $ in a regexp where it looks like a variable but is actually not.
Right, as in:
my $foo = qr!allan$!;
TextMate thinks that it's the variable $! instead of end-of-line followed by regexp delimiter. That's what I meant by the variable pattern having precedence.
But now let’s use / as delimiter instead:
my $foo = qr/test $//;
This is ambiguous.
It's not ambiguous. The end delimiter is the first non-escaped character that matches the start delimiter. Perl finds the end delimiter and then realizes that the $ must be an end-of-line marker. When using slashes as the delimiter, you have to write $/ as $/.
In this case the variable pattern doesn't know that $/ isn't a valid variable name. Do we have to recreate the variable pattern instead of importing it?
On 15. Feb 2007, at 19:00, Grant Hollingworth wrote:
[...]
But now let’s use / as delimiter instead:
my $foo = qr/test $//;
This is ambiguous.
It's not ambiguous. The end delimiter is the first non-escaped character that matches the start delimiter. Perl finds the end delimiter and then realizes that the $ must be an end-of-line marker. When using slashes as the delimiter, you have to write $/ as $/.
In this case the variable pattern doesn't know that $/ isn't a valid variable name. Do we have to recreate the variable pattern instead of importing it?
You can’t import it, but you can’t recreate it either, as you wouldn’t know what character to escape (and thus not allow as the first character of a variable).
But we can recreate a limited variable pattern that just disallows all the potential delimiter characters as the first character of a variable -- I guess that in practice, no-one would notice, and at least examples like from the OP won’t render the rest of the line/ document still inside the regexp.
-
Allan Odgaard -
Andy Armstrong -
Grant Hollingworth -
Marcus Ramberg