I wrote:
Oops. I got caught submitting a change without testing it. I don't seem capable of never repeating that mistake--that's where automated tests come in handy.
Is there any facility for creating automated tests for language grammar rules?
It would be useful to be able to define tests within rules or patterns such as:
test_matches = " _italic_ "; test_no_matches = "snake_case_word";
...or perhaps...
test_matches = { " _italic_ " = 1; "snake_case_word" = 0; " _italic_number_1_ _italic_number_2 " = 2; };
And then be able to run tests for a specific bundle (say from within the bundle editor) like one would unit tests, and see if they're green or if there's a problem.
Would it be possible to write a BundleTester bundle? I guess one would just need to parse the indicated bundle's language property list and run any tests found using Oniguruma. Would these test properties be otherwise ignored?
-- Daryl
On 4/18/07, Daryl Spitzer daryl.spitzer@gmail.com wrote:
I got around to apply it, thanks.
Thank you.
While I was in there, I made the same change to the 'markup.bold.twiki' match.
This won't work, since * is not a word character, so \b will actually have the opposite effect, i.e. making foo*bar*fud match the inner word as bold.
Oops. I got caught submitting a change without testing it. I don't seem capable of never repeating that mistake--that's where automated tests come in handy. (Which leads me to a question which I will post separately.)
Instead it should probably be (?<!\w) and (?!\w) before/after the match. I didn't make this change though.
I think you made the right call. Unlike snake_case_words, I have yet to run across a real-world need for asterisks embedded within words. We should wait to "fix" it until it is proven to be a problem.
-- Daryl
On 4/13/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 5. Apr 2007, at 22:09, Daryl Spitzer wrote:
It is a bug that words surround by underscores in snake_case_words in a TextMate Twiki document are italicized. (In this example, the word "case" is italicized.) When displayed in TWiki, those words are not italicized.
I made a small change to the Twiki language (in the Twiki bundle) to correct this--see the 'markup.italic.twiki' match in the attached patch.
I got around to apply it, thanks.
While I was in there, I made the same change to the 'markup.bold.twiki' match.
This won't work, since * is not a word character, so \b will actually have the opposite effect, i.e. making foo*bar*fud match the inner word as bold.
Instead it should probably be (?<!\w) and (?!\w) before/after the match. I didn't make this change though.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 18. Apr 2007, at 19:08, Daryl Spitzer wrote:
Oops. I got caught submitting a change without testing it. I don't seem capable of never repeating that mistake--that's where automated tests come in handy.
Is there any facility for creating automated tests for language grammar rules? [...]
Currently not, but in 2.0 my plan is to have “mate” (or more likely a dedicated shell command) expose a bit of TM functionality to the shell, this includes parsing a file and outputting the XML (as one can currently get as input from a TM command).
This will make it fairly simple to write scripts (or a framework) for testing grammars, something we definitely do want to have :)
One little nicety is that this can also perform benchmarks on grammars, reporting which rules the parser spends the most time with (making it easier to find problematic rules).
On Apr 18, 2007, at 1:57 PM, Allan Odgaard wrote:
On 18. Apr 2007, at 19:08, Daryl Spitzer wrote:
Oops. I got caught submitting a change without testing it. I don't seem capable of never repeating that mistake--that's where automated tests come in handy.
Is there any facility for creating automated tests for language grammar rules? [...]
Currently not, but in 2.0 my plan is to have “mate” (or more likely a dedicated shell command) expose a bit of TM functionality to the shell, this includes parsing a file and outputting the XML (as one can currently get as input from a TM command).
This will make it fairly simple to write scripts (or a framework) for testing grammars, something we definitely do want to have :)
One little nicety is that this can also perform benchmarks on grammars, reporting which rules the parser spends the most time with (making it easier to find problematic rules).
Awesome! Sign me up for some sweet test driven syntax creation goodness!
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
* Allan Odgaard throw-away-1@macromates.com [2007-04-18 11:57]:
This will make it fairly simple to write scripts (or a framework) for testing grammars, something we definitely do want to have :)
Oh that is so good. Right now I have a file full of test cases, but it's in no way automated.
What do you think of my proposal for specifying the tests within the language grammar rules or patterns?
-- Daryl
On 4/19/07, Grant Hollingworth grant@antiflux.org wrote:
- Allan Odgaard throw-away-1@macromates.com [2007-04-18 11:57]:
This will make it fairly simple to write scripts (or a framework) for testing grammars, something we definitely do want to have :)
Oh that is so good. Right now I have a file full of test cases, but it's in no way automated.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Apr 19, 2007, at 12:09 PM, Daryl Spitzer wrote:
What do you think of my proposal for specifying the tests within the language grammar rules or patterns?
I have to say I think that would make the language grammars seem too complicated, they are pretty complicated as it is.
But as I see it there are two different kinds of tests here. 1) very local tests. Those would perhaps fit in the language grammar rules. Their purpose is basically to say: "this regexp should be matching these cases". So these are I would say "pure regexp" tests. 2) more global tests. They would test whether a file as a whole is split up into the appropriate components. In other words, they would be testing to what extend the rules (which mind you might be coming from 3-4 different grammars) are tied together the right way. Those tests should probably be specifying that for instance "these lines should be matched as 'quote' ", "these should be matched as 'embedded'" and so on. So they should be slightly not too specific.
Just thinking out loud...
-- Daryl
Haris Skiadas Department of Mathematics and Computer Science Hanover College
-
Allan Odgaard -
Charilaos Skiadas -
Daryl Spitzer -
Grant Hollingworth -
Thomas Aylott (subtleGradient)