Collapse code fails in TM2 (Code Folding) about coffee-script-tmbundle

[dwt]

I'm suffering from this as well.

Is there an estimate when this can be fixed?

[jrus]

Fix it yourself! It’s not too hard to learn how TM foldings work. For instance, the Python pattern is currently:

{ foldingIndentedBlockStart = '^\s*(class|def|for|while|if|elif|else|with|try|finally|except)\b.*:\s*(#.*)?$'; }

[dwt]

Well, try as I might, I cannot get it to work. Whenever I have a -> in the regex it just fails to match anything.

It almost feels as if it is canceling out with some other rule from somewhere else. Maybe you can reproduce this and report a bug to TextMate from this - I'm just puzzled.

[alanhogan]

Reporting as a TM bug would make sense then… After all, the same bundle worked in TM v1, I’m fairly sure.

On Mar 15, 2012, at 1:25 PM, dwt wrote:

Well, try as I might, I cannot get it to work. Whenever I have a -> in the regex it just fails to match anything.

It almost feels as if it is canceling out with some other rule from somewhere else. Maybe you can reproduce this and report a bug to TextMate from this - I'm just puzzled.

---

Reply to this email directly or view it on GitHub:
#87 (comment)

[jrus]

Edit: Hmm. I’m getting some real weirdness around -> as well. Am asking Allan Odgaard about it. [...]

Unfortunately, I don’t have time today to do more debugging of the CoffeeScript grammar, or to rewrite it to better follow typical TM grammar conventions. I’ll try to follow this up sometime in the next few days though.

[jrus]

Okay, @alanhogan @dwt the issue is that the grammar has foldings embedded (this is the way things were done in TM1). You have to go find the CoffeeScript.tmLanguage file on disk (an XML plist), and remove the foldingStartMarker and foldingStopMarker key-value pairs.

[jrus]

@alanhogan @dwt @jashkenas

Okay, to mostly hit all the cases I’ve seen – and it seems to be working great – I deleted those two keys (i.e. foldingStartMarker and foldingStopMarker) from the language grammar itself and from any settings files, and added the following settings file:

{ foldingIndentedBlockStart = '(?x)
    \b class \b |            # class definition
    [=-]> \s* (\#.*)? $      # line-ending function arrow
    ';
}

Scoped to source.coffee -(source.coffee string). [It’s not clear to me whether it’s desirable to fold inside block comments or not.] This won’t deal with the edge case where the word class occurs inside a string that ends before the end of the line, or inside a comment (false positives), but those edge cases are really hard to catch without either tremendously complicating the rule or else getting false negatives, since arbitrary expressions can go inside the thing that gets assigned to a class, as in, to take an extreme example:

Baz = wrapper class a.b(c..., new (class extends Bar) '#', y: ->)[1] extends Foo

(Though admittedly, the current language grammar doesn’t bother to handle most tricky edge cases, resulting in fairly frequent wrong/missing scopes. Still, we might as well do the best we reasonably can in the folding rule, and we can fix the rest of the grammar some other day.)

[jashkenas]

Is this something that would get backported for TM1? Or is it a TM2-specific change?

[jrus]

The indented block foldings are TM2 specific.

[dwt]

Uhm, but that means that you can't have one bundle that works with tm1 and tm2?

I would consider that a bug, the tm2 settings should override the tm1 settings so they can coexist in one bundle allowing backwards compatibility.

If necessary Allan can add another setting that tells tm2 to override that other key and then deprecate it once tm2 is out and final.

[jrus]

That’s silly. TM1 is on the way out, and all the bundles can trivially be updated. The language grammar system, the scoping rules, and many other aspects of the app have been completely rewritten with new and better features. Once people actually start taking advantage of those, the resulting bundles will not function the same in TM1. The community hasn’t really stepped up to the plate yet to adopt all the neat new features, but it’s only a matter of time.

If you want a legacy TM1 bundle, there’s nothing wrong with keeping that one around separately someplace.

[dwt]

Well, then how do I install separate bundles for tm1 and 2 again?

[dwt]

Is there already a branch with the changes outlined above that I can test? I'll be working with coffee script quite a bit today.

[jrus]

@dwt see http://blog.macromates.com/2011/locating-bundles/

As for a branch w/ the changes above, my fork of the bundle does this, and also has improved compile/run commands.

https://github.com/jrus/coffee-script-tmbundle/

Note that I haven’t really been keeping up with jeremy’s fork, planning at some point to just rewrite the language grammar and fix up the commands &c. to be more "textmate-ish"... best laid plans and all that.

[dwt]

Am 22.03.2012 um 04:03 schrieb Jacob Rus:

@dwt see http://blog.macromates.com/2011/locating-bundles/

Got it, thanks!

Martin

[alexandertrefz]

@jashkenas Now that TM2 is really moving again, after its OpenSourcing, can we get this in maybe? Or have a separate TM2 branch in this Repo on which this can go in?

[Hoverbear]

+1, this is still an issue.