[TxMt] [REVIEW] JavaScript

[Thomas Aylott]

On Sun, Dec 30, 2007 at 2:56 AM, Daniel Stockman
<daniel.stockman at gmail.com> wrote:
> (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
>


I just submitted a few changes for the regex literal issues.
The latest review javascript bundle should have all that fixed now.
It also looks like the folding issue isn't a problem with the current
trunk version of prototype.

Please send me some more bugs to fix and I'll try to get on them soon.

I'm also going to look into the regex performance and see what I can
do to keep such massive files from having that horrible slowdown when
parsing the file. I'll bet there's some terrible backtracking going
on.

--Thomas Aylott -- subtleGradient--