The following two valid PHP snippets trip up the PHP grammar in TextMate. Mostly because of unusually nested quotes and braces:
Snippet #1: <?php $str = array("Foo", "Bar"); echo "Name: {$str[($str[1]) ? 1 : 0]}"; // Should echo "Name: Bar" ?>
The text "($str[1" appears highlighted as a syntax error
Snippet #2 <?php $insert = mysql_query("INSERT INTO `catalogue` SET `model`='{$_POST["page_row{$count}_model"]}', `type`='{$_POST["page_row{$count}_type"]}', `updated`=UNIX_TIMESTAMP() ;"); ?>
Everything in the document after this snippet is treated as a string.
Hopefully these are simple grammar file fixes :)
Cheers, Brian
GreyWyvern bhuisman@greywyvern.com wrote (Fri, 22 Jan 2010 14:34:50 -0800):
The following two valid PHP snippets trip up the PHP grammar in TextMate. Mostly because of unusually nested quotes and braces:
Well, they are not only unusually nested... additionally, they are not exactly what you might call "clean code"...
Snippet #1:
<?php $str = array("Foo", "Bar"); echo "Name: {$str[($str[1]) ? 1 : 0]}"; // Should echo "Name: Bar" ?>
The text "($str[1" appears highlighted as a syntax error
Snippet #2
<?php $insert = mysql_query("INSERT INTO `catalogue` SET `model`='{$_POST["page_row{$count}_model"]}', `type`='{$_POST["page_row{$count}_type"]}', `updated`=UNIX_TIMESTAMP() ;"); ?>
Everything in the document after this snippet is treated as a string.
Hopefully these are simple grammar file fixes :)
I guess they are, but writing your PHP code in a different, cleaner and maybe even a teeny weeny bit faster code solves your problem, too:
<?php $str = array("Foo", "Bar"); echo 'Name: ' . $str[($str[1]) ? 1 : 0]; // will echo "Name: Bar"
$insert = mysql_query('INSERT INTO `catalogue` SET `model`="' . $_POST["page_row{$count}_model"] . '", `type`="' . $_POST["page_row{$count}_type"] . '", `updated`=UNIX_TIMESTAMP();'); ?>
Kind regards, Tobias Jung
Tobias Jung-2 wrote:
Well, they are not only unusually nested... additionally, they are not exactly what you might call "clean code"...
[snip]
I guess they are, but writing your PHP code in a different, cleaner and maybe even a teeny weeny bit faster code solves your problem, too:
<?php $str = array("Foo", "Bar"); echo 'Name: ' . $str[($str[1]) ? 1 : 0]; // will echo "Name: Bar" $insert = mysql_query('INSERT INTO `catalogue` SET `model`="' . $_POST["page_row{$count}_model"] . '", `type`="' . $_POST["page_row{$count}_type"] . '", `updated`=UNIX_TIMESTAMP();'); ?>
Kind regards, Tobias Jung
Thank you :) I understand how to make my code work with TextMate's grammar rules, however I would rather have the grammar rules work for all valid syntax, rather than just "clean" syntax.
Just reporting what I'm finding here, is all; and hoping that TM's grammar can be made more robust in this case.
Cheers, Brian
GreyWyvern bhuisman@greywyvern.com wrote (Fri, 22 Jan 2010 15:13:39 -0800):
I understand how to make my code work with TextMate's grammar rules, however I would rather have the grammar rules work for all valid syntax, rather than just "clean" syntax.
And I would not like to see slow TextMate down (using much more complex regex syntax for the grammar rules) because some people like to write code that is, by ALL means that I can think of, disadvantageous at least.
Just reporting what I'm finding here, is all; and hoping that TM's grammar can be made more robust in this case.
If it can be done without slowing syntax coloring down, I'm with you. But I REALLY wouldn't like a slowdown just for code... see above.
Regards, Tobias Jung
On 2010-01-22 17:24:23 -0600, Tobias Jung said:
And I would not like to see slow TextMate down (using much more complex regex syntax for the grammar rules) because some people like to write code that is, by ALL means that I can think of, disadvantageous at least.
This should be more than possible without slowing anyone's computers down. If our computers can render full-screen bluray movies and better-than-1080p video games, I think they can parse text.
Sean
Sean Gilbertson sean.gilbertson@gmail.com wrote (Wed, 10 Feb 2010 09:56:45 -0600):
And I would not like to see slow TextMate down (using much more complex regex syntax for the grammar rules) because some people like to write code that is, by ALL means that I can think of, disadvantageous at least.
This should be more than possible without slowing anyone's computers down. If our computers can render full-screen bluray movies and better-than-1080p video games, I think they can parse text.
On my Mac mini 2 GHz Intel Core 2 Duo, TextMate already needs a few seconds to parse long PHP files. Not long enough to bother me in any way but if it'd take, say, twice as long, I'd call it a nuisance.
And in case you don't believe that parsing text CAN occupy your computer for a VERY long time:
1. Copy the section between the equals signs to TextMate (keep the quotation marks): =========================================== "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." ===========================================
2. Copy the following regular expression to TextMate's search box (don't forget to tick "Regular Expression", and again: Keep the quotation marks) and hit "Next". =========================================== "([^"\]+|\.)*" ===========================================
3. TextMate will select the complete text in no time.
4. Now, delete the quotation mark at the end of the text (i.e. behind 'laborum.').
5. Make sure that you have no other files open in TextMate that you haven't saved yet.
6. Put the cursor at the beginning of the text, and hit command + G to search again.
==> TextMate will stall completely, eating about 100% of your CPU power according to Activity Monitor.
The thing is, TextMate doesn't crash. It's still trying to find text matching the regular expression. I don't know how long it'll take before TextMate will see that the regex doesn't match at all, I've always used a force quit after five or six minutes.
Now, of course changing TextMate's PHP grammar will most likely not result in parsing PHP files for years... ;-)
This, of course, is an extreme example that merely shows that the wrong regex used on the wrong text (keep in mind that it works fine until you delete the closing quotation mark) CAN indeed be harder than rendering full-screen bluray movies.
Thus, it _is_ possible that changing the regex might result in slower syntax coloring.
I'd like to stress again that I don't believe that changing the grammar will be bad. But it is a matter that is not to be taken lightly.
Kind regards, Tobias Jung
On Feb 10, 2010, at 11:07 AM, Tobias Jung wrote:
"([^"\]+|\.)*"
Nice poison regex. Took me awhile to recognize why the '\'...
Yes, I suppose alternating between a greedy class match and a non-existent string on every character in a long file could take a while to finish...
And I suspect it wouldn't be hard to accidentally produce a regex that had similar behavior -- in fact, Murphy almost insists.
Thus, it _is_ possible that changing the regex might result in slower syntax coloring.
I'd like to stress again that I don't believe that changing the grammar will be bad. But it is a matter that is not to be taken lightly.
Would be nice to have the ability to interrupt TM during a runaway regex expression (or other effort), but I suppose that would merely slow down every regex search.
joe
On 22 Jan 2010, at 23:34, GreyWyvern wrote:
[...] Hopefully these are simple grammar file fixes :)
GitHub is down, but will file this as http://github.com/textmate/php.tmbundle/issues/1 when it is up again.
It is a grammar fix, but I think we have a giant regexp to match variables with array subscripts in strings, so given that it seems PHP (no longer?) restricts array subscripts in embedded variables to regular languages, it may require a restructuring of the rule in question (to a begin/end rule).
-
Allan Odgaard -
GreyWyvern -
joseph davison -
Sean Gilbertson -
Tobias Jung