[TxMt] [REVIEW] JavaScript

[Daniel Stockman]

(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)
> Those few of you who care, please let me know what I need to do  
> before I can replace the core bundles with these guys.

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.
> The Review Prototype bundle is NOT upgraded for the latest version  
> of prototype.
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