(forgive my noobishness, I had to re-join the list after a long period of inattention, and cannot respond directly to the original message, from Thomas Aylott) I was really excited to see activity related to JavaScript in / Review, and I immediately switched my checkouts to track the JavaScript and Prototype bundles in Review. The irony of someone who follows the commit log feed yet had to re-subscribe to the mailing list is exquisite, I know. I've been using them for the past few weeks with few (if any) noticeable problems, using the Prototype bundle as my chosen grammar for *.js. That is, until today, when I decided to go poking about the latest Prototype trunk. The file generated by `rake dist` has _never_ been small, I'll grant, but I don't recall so much chugging and whinging by my 2.2Ghz MacBook, or seconds-long gaps of white syntax colorless-ness when switching tabs (a beachball will occasionally pop up for a few seconds, even). My wild shot-in-the-dark hypothesis is that it might be related to the increased number of `include $base` declarations in the "new" grammar. To reiterate, this only occurs on files like the `rake dist`-generated prototype.js, which itself is over 4,000 lines of syntactically dense, idiomatic (and often beautiful) JS. There seems to be a regression in the regex literal highlighting, as it no longer works when the RegExp literal notation is used as a member of an object with any space separating the key's colon delimiter and the literal itself. The literals are colored fine when it begins on the very first character of the line, or when immediately following a parenthesis. Line 275+ of prototype/trunk/ src/selector.js is a perfect example of this regression. I narrowed down the cause of this anomaly to the 'string.regexp.js' key of the Embedded grammar, specifically the `begin` regexp: (?<=[=(:]|^|return)\s*(/)(?![/*+{}?]) The lookbehind seems to be blocking it; when I remove it, the RegExp literals in the object values highlight as intended. This does cause any single `/` to color everything after it as a regexp, but adding an alternate end-of-line anchor ($) to the negative lookahead seemed to fix that. (?![/*+{}?]|$) There is also an oddity with the folding markers, which appears to be related to the block comment syntax. Line 135 of prototype/trunk/ src/ajax.js: 'Accept': 'text/javascript, text/html, application/xml, text/ xml, */*' Again, inside an object literal, but this time the "*/*" seems to make the folding parser think "I need to start a new fold here!", when in fact it is the last member of the object, and should have no folding marker whatsoever. Take away the second * (thus turning it into a block comment closing delimiter), and the folding marker disappears. I was unable to parse the gargantuan folding regexps in the grammar clearly enough to suggest a solution. I'd be willing to pitch in on this effort, if you (or whomever "owns" the bundle) would like. I've done a bit of local hacking on various bundles, and I can certainly provide examples off-list. The Prototype grammar itself could use a little cleaning up, I'm sure. Big thanks to all the bundle contributors for continuing to make TextMate great! (Oh, and Allan, too :D) ~ Daniel Stockman evocateur.org ______________________________________________________________________ For new threads USE THIS: textmate(a)lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

I just submitted a few changes for the regex literal issues. The latest review javascript bundle should have all that fixed now. [...] I'll bet there's some terrible backtracking going on.