foo("a" + "b" + "c" + "d" + "e" + "f" + "g" + "h" + "i" + "j" + "k" + "l" + "m" + "n" + "o" + "p" + "q" + "r" + "s" + "t" + "u")
var whyAmIYellow = 1;

I'm not sure if this is the right project to report this issue in, so my apologies if I'm in the wrong place.

It looks like the syntax highlighting gets confused on the provided text. You'll notice after the q we start getting yellow plusses instead of read. The subsequent lines are also yellow. The last span on this line contains q through the end of the line and no punctuation definition string end.

I'm on Atom 0.144.0 on Mac. I also repro'd on my windows machine.

I'm happy to help debug further, but am not too sure where to start.

Everytime I change a line and save, I lose the line with focus.

Have any idea how fix it?

Sorry for not being able to investigate further, I'm new to Atom. I'm using Atom Dark, but I also tried Solarized and the same problem.

Generators are not being identified as functions:

function* gen() { ... }

Every time a line starts with default (e.g. in JSON) language-javascript wants to decrease the indent, regardless of whether its part of a larger word. The solution is to ensure that there is a word boundary after default and case before decreasing the line indent.

E.g.

{
  defaultSerializer: '-rest'
}

Is changed to

{
defaultSerializer: '-rest'
}

Here is the gif image of the issue

This snippet should not add space after comma.

See FacebookProvider

Adding a comma after the line break colors the arg correctly but isn't ideal

If you use the second tab stop to enter a non-string value, the third and fourth tab stop no longer match anything useful (a string value, the trailing comma).

More pressing is the issue that if you hit cmd-enter after tabbing to the second tab stop (and potentially replacing the value with a non-string), trying to resolve a string to a snippet will tab back to the previously mentioned now-useless 3rd and 4th tab stops. This is an issue when trying to use snippets to create multi-line objects, as you either have to tab an extra time for no reason, or move the cursor to break the previous snippets tab chain.

Steps to repro:

1. type :
2. hit tab
3. hit tab to select "value"
4. type a new value (ex: myFunction)
5. hit cmd-enter to insert a new line
6. type :
7. hit tab

Expected behavior:
: expands to a new key:"value" snippet

Observed behavior:
yFunctionon the previous line is selected

Note that this behavior is only observed from the second tab stop.

I was just invited to use Atom. I have been using Brackets.io largely due to the great extension support for features like JSHint. I intentionally made some syntax errors in some of my existing scripts and the editor did not flag them as a problem.

It would be very helpful to get JSHint support so I can make the switch to Atom which look very promising.

https://github.com/cfjedimaster/brackets-jshint

This pattern breaks syntax highlighting. Everyting after this line seems to be part of the regexp

var pattern = /\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b/;

regards

In Javascript, each line in a multi-line string must be ended with a \. Atom does not recognise this need, and highlights the whole string rather than warning users about missing \s.

If I disable language-javascript, I not can enable again:

Have any file to change for enable it?

I'm not sure how best to document this issue other than describing the behavior. The subject of the issue sums it up pretty well, actually. I'll be editing a file, and as I scroll down am met with large chunks of the file that are pure white text. Sometimes if I keep scrolling further, the rest of the file looks good (just a big white wall in the middle).

If I close the file and re-open it, it seems to usually clear up the issue.

The setTimeout snippet (timeout) attempts to select the anonymous function as a tab stop, but the closing curly on the function body closes the selection.

setTimeout(${2:function () {\n\t$3\n}}, ${1:10});

It expands to this with the second tab stop selection acting like so (notice the selection does not include the })

I tested escaping the curly brace (the way TextMate handles this), but that didn't seem to solve the problem.

Noticed this while reading the d3 source:

https://gist.github.com/semperos/cb77a1c45b0c0aebfc0a#file-d3-js-L7995

Starting on that line (7995) at this point:

",", d3_svg_lineDot4(d3_svg_lineBasisBezier3, py) ];

From ",", through this line and the rest of the file, the syntax highlighter does not consider the string "," closed or balanced, resulting in the entire rest of the file being highlighted like a string.

You can see two function in the screenshot below ("compile" and "compileTarget" one of these has syntax highlighting and the other one hasn't)

As in https://github.com/Benvie/JavaScriptNext.tmLanguage for Sublime.

The syntax highlighting seems to stop working properly if a regular expression contains a double quote character:

Screenshot taken in Atom v0.106.0 (language-javascript v0.28.0) with no extra plugins enabled.

I'm on Atom 0.92.0 with Language Javascript 0.24.0. The issue doesn't happen with this plugin disabled. No logs in the dev console or Console.app that I can find.

There is a thread on the forums: http://discuss.atom.io/t/bug-adding-comment-to-javascript-file-crashes-atom/6786

Steps to reproduce:

1. Take the source below.
2. Put the cursor at the very beginning
3. Press return
4. Press up
5. Press /

Expected:

A "/" character should be entered on a new line at the top of the document

Actual:

Atom hangs.

Sample source:

/// The parser's job is to read some source and extract the markdown. The hard part of the parsing
/// is handled by a packrat parser generated from `grammar/docparser.peg`. This module wraps the
/// parser to provide a higher-level interface.

var docparser = require('../grammar/docparser');


docparser.Parser.DocBlock = {
    isDocBlock: true,

    // Extracts the markdown from the node.
    getDocs: function () {
        var docs = '';
        this.elements.forEach(function (line) {
            docs += line.docs.textValue;
        })
        return docs;
    }
}


/// `parse(source)`
/// --------------------------------------------------
/// **TODO**: Summary
///
/// ### Arguments
/// 1. `source` *(String)*: The source code to parse.
///
/// ### Returns
/// *(Array of Strings)*: The blocks of markdown documentation in the source.

exports.parse = function (source) {
    var ast = docparser.parse(source);
    var docs = [];
    ast.elements.forEach(function (block) {
        if (block.isDocBlock) {
            docs.push(block.getDocs());
        }
    })
    return docs;
}

Hi,

It seems that there is a problem with ES6 string template :

Maybe ES6 is not supported yet ?

I'm on linux Mint 17 and my version of atom is 0.125.0

This is what it looks like in Atom:

And this is what it looks like in Sublime Text:

Сode:

            result.rating = _
                .pluck(data.category_users, 'rate_avg')
                .reduce(function(a, b) { return a + b })
                / data.category_users.length;

Line / data.category_users.length; treated as regexp.

Might or might not be related to #27 - But this gist doesn't color correctly. The word "keyword" is highlighted just like the string above instead of as a param key.

https://gist.github.com/cyberwombat/7c3a98448e90b0600e5e

When parsing the file contained in https://gist.github.com/jagill/03706598d1d2555c3b50, it stops highlighting correctly at line 1, column 170. Notice that everything following has a string syntax color.

This is v0.39.0 of the language-javascript package, v 0.125.0 of atom, on OS X 10.9.4 build 13E28.

just creates a anonymous function

The version I have in the editor says 0.28.0 and doesn't prompt or say there is an update. Is this an atom bug or is this module not being published correctly?

This is most likely a core Atom issue, but I have no idea where I would even log that.

In the JavaScript language snippets specifically, snippets with multiple lines using the \t character will use spaces for the first instance, then hard tabs for subsequent instances.

This is visible using the try snippet which ends up with mixed tabs and spaces:

try {
  statements // The \t is two spaces.
} catch (variable) {
    statements // The \t is a hard tab; two spaces and a hard tab.
} finally {
    statements // Two spaces and a hard tab.
}

I'm thinking that the first \t is being ignored while the next two are included; however, atom isn't using the user settings of soft tabs.

Hi,

I use the following regex to validate URIs:

/^[a-z](?:[-a-z0-9\+\.])*:(?:\/\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:])*@)?(?:\[(?:(?:(?:[0-9a-f]{1,4}:){6}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|::(?:[0-9a-f]{1,4}:){5}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){4}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:[0-9a-f]{1,4}:[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){3}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,2}[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:){2}(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,3}[0-9a-f]{1,4})?::[0-9a-f]{1,4}:(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,4}[0-9a-f]{1,4})?::(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3})|(?:(?:[0-9a-f]{1,4}:){0,5}[0-9a-f]{1,4})?::[0-9a-f]{1,4}|(?:(?:[0-9a-f]{1,4}:){0,6}[0-9a-f]{1,4})?::)|v[0-9a-f]+[-a-z0-9\._~!\$&'\(\)\*\+,;=:]+)\]|(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])){3}|(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=@])*)(?::[0-9]*)?(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*|\/(?:(?:(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))+)(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*)?|(?:(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))+)(?:\/(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@]))*)*|(?!(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])))(?:\?(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])|[\x{E000}-\x{F8FF}\x{F0000}-\x{FFFFD}|\x{100000}-\x{10FFFD}\/\?])*)?(?:\#(?:(?:%[0-9a-f][0-9a-f]|[-a-z0-9\._~\x{A0}-\x{D7FF}\x{F900}-\x{FDCF}\x{FDF0}-\x{FFEF}\x{10000}-\x{1FFFD}\x{20000}-\x{2FFFD}\x{30000}-\x{3FFFD}\x{40000}-\x{4FFFD}\x{50000}-\x{5FFFD}\x{60000}-\x{6FFFD}\x{70000}-\x{7FFFD}\x{80000}-\x{8FFFD}\x{90000}-\x{9FFFD}\x{A0000}-\x{AFFFD}\x{B0000}-\x{BFFFD}\x{C0000}-\x{CFFFD}\x{D0000}-\x{DFFFD}\x{E1000}-\x{EFFFD}!\$&'\(\)\*\+,;=:@])|[\/\?])*)?$/i

This seems to confuse the JavaScript syntax highlighter and yields this (note the following if statement isn't highlighted like it should):

$ atom --version  
0.136.0

Mac OS X 10.9.5
No errors in the developer console.

This issue can include this earlier one.

It seems that a lack of braces break the auto indentation. For example:

if (true)
  i = 1;
else
  i = 2;

Turns into:

if (true)
  i = 1;
  else
    i = 2;

In https://github.com/atom/language-javascript/blob/master/grammars/javascript.cson
There seems to be a problem with a particular regular expression.

If you try to code the line

a.push('x' + y + ':function()');

I think it matches the pattern

'begin': '(?:((\')(.*?)(\'))|((")(.*?)(")))\\s*:\\s*\\b(function\\*?)?\\s*(\\*?)(\\()'

because as I understand it, this has a quoted string on the line (which uses .*? to match the second apostrophe) using the first and third ones as the markers for the string. then there is a colon and the word "function" followed by some stuff and then a "("

I don't know this particular regular expression language well enough to change (\')(.*?)(\')) to exclude the apostrophe being matched by the (.*?)

What regular expression library defines this pattern? Is it a Ruby thing?
And what is a cson file anyway? It reminds me of json.

The highlighting is not consistent for these two lines. In addition having a ' in the second line messes up highlighting for the rest of the file.

var b = /sdf'/;
var a = 'a' + /sdf'/;

In Atom's developer tools I found var and function are treated as ".storage.modifier" and ".storage.function".

But according to ECMAScript 5.1, var and function are keywords:
http://www.ecma-international.org/ecma-262/5.1/#sec-7.6.1.1

Here's a sample snippet that breaks Atom's JavaScript syntax highlighting. I've noticed this on several extremely long lines of regular expressions.

// everything up here is highlighted correctly

if(!String.prototype.isValidEmailAddress) {
    String.prototype.isValidEmailAddress = function() {
        var pattern = new RegExp(/^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/i);
        return pattern.test(this);
    };
}

// the rest of the file is not properly highlighted

The following statement confuses javascript highlighting (The string highlighting right before XXX gets stuck and applies to the rest of the statement). Interestingly changing the 2nd variable from s.B to just B causes it to break somewhere else.

A = 'http' + (s.B ? 's' : '') + '://' + C + '/foo/' + s.D + '/' + (s.E ? '1' : '2') + '/' + s.F + (s.G ? 'T' : '') + '/' + XXX + '?i=1&j=1' + (q ? q : '') + '&k=1';

I'll note I didn't produce this code, I just ran across it when my screen turned green half-way through a file I was reviewing!

A gif probably explains it best:

Firstly, I'd contend that the ]) shouldn't be automatically indented, but I can live with that.

Main point: the {whatever} line automatically outdents as soon as I type the first { (presumably because it thinks it's opening a block rather than an object), and then continually tries to outdent whenever I type any more characters on the line (the re-indentation in the gif is me hitting ctrl+])

Been happening in atom --safe built off master for the last couple of days, presumably since the update to [email protected] in relation to e38f1cd

The $ character is erroneously included in the list of operators, causing incorrect highlighting of variables containing it.

The JS comment on the line below isn't highlighted when viewing the README, but is highlighted as a comment in the editor:

onAdd: function (/**Event*/evt){

I've contacted @github about this and they suggested this:

We use open source TextMate-style language grammars for syntax highlighting. You can view the list of grammars for specific languages here:

https://github.com/github/linguist/blob/master/grammars.yml

The fastest way to get this fixed would be to find the issue tracker for the specific grammar and open an issue or contribute a fix there.

Once the issue has been fixed, let us know via a Linguist issue and we'll update our version of the grammar.

Indention got much better in the latest releases, but there are some glitches in js, which seem to behave similar to the problem mentioned in atom/language-html#44:

Atom 0.152, OSX

/* source for copy */
var test = 1,
    test2 = 2,
    test3 = 3;

/* pasted */
    var test = 1,
    test2 = 2,
    test3 = 3;

/* source for copy */
$.getJson()
  .then()
  .then()

/* pasted */
  $.getJson()
  .then()
  .then()

/* source for copy */
function( [ '1',
            '2',
            '3',],
            function( One, Two, Three) {
            }
);

/* pasted */
function( [ '1',
'2',
'3',],
function( One, Two, Three) {

}
);

The result of sublime3:

/* source for copy */
var test = 1,
    test2 = 2,
    test3 = 3;

/* pasted */
var test = 1,
    test2 = 2,
    test3 = 3;

/* source for copy */
function( [ '1',
            '2',
            '3',],
          function( One, Two, Three) {

          }
);

/* pasted */
function( [ '1',
            '2',
            '3',],
          function( One, Two, Three) {

          }
);

reserved words are highlighted when used as property names on an object (which is allowed in ES5)

more annoyingly, if 'case' or 'default' is used as a property name, the indentation on that line resets

I like to use spaces when source is already using spaces.
It would be great to have a checkbox for soft tabs.

see also atom/atom#3719

Since I see a lot of browser stuff in the grammars, I presume that adding some node-specific stuff wouldn't be out of the question?

I'm thinking things like:

• module
• exports
• require
• __filename
• __dirname

I can live w/o the last 2, the first 3 are pretty important though. (and I'm sure there are others I'm missing)

Unable to download https://www.atom.io/api/packages/language-javascript/versions/0.12.0/tarball: 400 Bad Request Repository inaccessible

Atom version: 0.138.0

The current javascript grammars seem to not notice regular expressions in some contexts which it possibly should.

The possible bug in action:

http://g.recordit.co/BUxtL7q2UX.gif

What I would expect: The regex passed as an argument would be colorized as a normal regex, preventing the double quotes grammar from kicking in.

The final result of atom/snippets#11 allows a snippet to have duplicate names, very useful for most snippets that use the same name in multiple places.

For example:

"for": {
  "prefix": "for",
  "body": "for (var i = 0; i < ${1:array}.length; i++) {\n\t${2:array}[i]\n}"
},

can now be converted to:

"for": {
  "prefix": "for",
  "body": "for (var i = 0; i < ${1:array}.length; i++) {\n\t${1:array}[i]\n}"
},

I tried this by adding

{
  ".source.js": {
    "xxx": {
      "prefix": "xxx",
      "body": "for (var i = 0; i < ${1:array}.length; i++) {\n\t${1:array}[i]\n}"
    },
  },
}

to my snippets and it works just fine and looks sexy!

I'm not sure if this a duplicate of #40, but the following code breaks the syntax highlighter:

var f = function() {
  var optional, slash, format, capture, star;
  return '' + (optional ? '' : slash) + '(?:' + (optional ? slash : '') + (format || '') + (capture || (format && '([^/.]+?)' || '([^/]+?)')) + ')' + (optional || '') + (star ? '(/*)?' : '');

  // Syntax highlight is now broken
};

f();

Atom 0.107.0

After this regex all code is highlighted as regex.

The switch statement in JavaScript files is not being indented correctly.

Each case statement is aligning under the break statement directly above it, rather than aligning with the preceding case statement.

A screenshot of this is:

Hello,

Currently myObj.init().foo.bar() and some() are displayed in a single color.
It would really great the functions and methods are Highlighted.

It's possible?