This is a corner-case I found with indentation. I've tried to simplify it down from a long set of database methods using knex.js, but it does appear to depend on the interaction of several factors. Basically, code that appears sound translates in a way that a variable is out of scope.
Here's the basic problematic case:
a
.b () ->
x = c
.d () ->
@e()
.f
x
Under CS 1.8.0, this translates to:
a.b(function() {
var x;
return x = c.d(function() {
return this.e();
}).f;
});
x;
And x is out of scope, apparently lifted out of the b callback. Removing the call to .d and its method makes the scoping work right. So, interestingly, does removing the .f line. More curiously, removing all the indentation to the b callback also makes everything fine. i.e.,
a
.b () ->
x = c
.d () ->
@e()
.f
x
works right. So this appears to be a case where additional indentation across a consistently intuitive block breaks scoping inside that block. The workaround seems to be related to #3620, basically, never using indentation for method calls, but this does negatively affect readability.
This is a corner-case I found with indentation. I've tried to simplify it down from a long set of database methods using knex.js, but it does appear to depend on the interaction of several factors. Basically, code that appears sound translates in a way that a variable is out of scope.
Here's the basic problematic case:
Under CS 1.8.0, this translates to:
And
x
is out of scope, apparently lifted out of theb
callback. Removing the call to.d
and its method makes the scoping work right. So, interestingly, does removing the.f
line. More curiously, removing all the indentation to theb
callback also makes everything fine. i.e.,works right. So this appears to be a case where additional indentation across a consistently intuitive block breaks scoping inside that block. The workaround seems to be related to #3620, basically, never using indentation for method calls, but this does negatively affect readability.