"Smaller screens" means screens smaller than 820px wide. That's the smallest
width that the current design looks good at.
I tried to not change the current design in any way and to make as few changes
as possible.
This is what happens on smaller screens:
- The navigation bar is no longer fixed to the viewport, but always at the top
of the page.
- The navigation bar is vertical rather than horizontal.
- CoffeeScript code is above the compiled JavaScript rather than having them
side by side.
This allows for a larger text size, which is more compfortable to read, and no
horizontal scrolling, which many find difficult to use.
This let's you do things like:
fullName = ({first = 'John', last = 'Doe'}) -> "#{first} #{last}"
Note: CoffeeScrits treats `undefined` and `null` the same, and that's true in
the case of destructuring defaults as well, as opposed to ES2015 which only uses
the default value if the target is `undefined`. A similar ES2015 difference
already exists for function parameter defaults. It is important for CoffeeScript
to be consistent with itself.
fullName2 = (first = 'John', last = 'Doe') -> "#{first} #{last}"
assert fullName('Bob', null) is fullName2(first: 'Bob', last: null)
Fixes#1558, #3288 and #4005.
Let me know if there's something I should be doing differently as this is my first contribution to coffeescript.
I fixed the reported issue where a generated variable could clash with a user-defined one in a try/catch block.
I added a test for a few scenarios with different variable names for a try/catch, to confirm the fix and avoid regressions.
Testing with `'[object Array]' is Object::toString.call element` allows arrays from another JS context to be properly handled. The specific use case here is to support jest, which sets up JS contexts using Node/io.js's "vm" module. This approach works in ES3 environments in contrast with ES5's `Array.isArray`.
If you passed an array of tokens (as opposed to a string of code) to
`CoffeeScript.nodes`, its attempts to prettify error messages would break. Now
it does not attempt to prettify error messages in that case anymore (because it
is not possible to prettify the errors without a string of code).
The repl was affected by the above bug.
Fixes#3887.
Instead of mapping all generated spaces and semicolons and newlines
to the source position (0,0), we avoid generating sourcemap information
for generated space-or-semicolon-only fragments.
(In addition to shortening sourcemaps, this fixes a correctness issue
where an empty fragment at the beginning of each line maps from (0,0),
but in a bare program, that position at the begining of the line
should map from the actual source line. When this conflict occurred,
(0,0) would win, resulting in an incorrect sourcemap, where each
top-level function call mapped to (0,0).)
