atom / language-javascript Goto Github PK
View Code? Open in Web Editor NEWJavaScript language package for Atom
License: Other
JavaScript language package for Atom
License: Other
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?
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
Generators are not being identified as functions:
function* gen() { ... }
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
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'
}
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 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
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.
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
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.
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.
The $ character is erroneously included in the list of operators, causing incorrect highlighting of variables containing it.
As in https://github.com/Benvie/JavaScriptNext.tmLanguage for Sublime.
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.
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.
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.
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
Unable to download https://www.atom.io/api/packages/language-javascript/versions/0.12.0/tarball: 400 Bad Request Repository inaccessible
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:
:
tab
tab
to select "value"
myFunction
)cmd-enter
to insert a new line:
tab
Expected behavior:
:
expands to a new key:"value"
snippet
Observed behavior:
yFunction
on the previous line is selected
Note that this behavior is only observed from the second tab stop.
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.
just creates a anonymous function
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)
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
A "/" character should be entered on a new line at the top of the document
Atom hangs.
/// 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;
}
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 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'/;
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!
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!
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.
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.
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;
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.
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.
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
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.
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) {
}
);
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.
С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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.