I'm trying to make ace editor not count the following as "improper syntax" and be used for templating. Currently, I haven't been able to find anything similar that helps me work with ace and edit this. The closest I've found is Ace editor: customizing syntax error gutter which didn't really point me in a direction?
I want it so ace doesn't interpret:
var derp = %{ (whatever can go in here) }%;
both %{ and %{ respectively as an error.
Ace uses jshint for syntax checking which is not very extensible.
If you do not have a better syntax checker, you can try hooking into https://github.com/ajaxorg/ace/blob/v1.1.8/lib/ace/mode/javascript_worker.js#L118
and replace %{ ... }% blocks with expression/* ... */ like
value.replace(/%\{([^}]|}[^%])*}%/g, "window/*$1*/")
the expression is needed to keep js valid and comment to keep lines
Related
Is there an option to and/or how do I suppress errors like the following?
175,14:['tracker'] is better written in dot notation.
If it's a feature and not a bug, place this at the top of your file.
/*jshint sub:true*/
If it's a bug, you should refactor your code
foo['tracker'] = bar // from this...
foo.tracker = bar; // to this!
Good post on the reasons here: https://stackoverflow.com/a/2001410/94668
As suggested by: #ThorSummoner you can use below in your .jshintrc file
"sub": true
In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax. The identifier of this warning is W069.
This means you can tell JSHint to not issue this warning with the /*jshint -W069 */ directive.
You can even wrap several lines of code and then reenable the warning as the example below (with a note to future you why it was a good idea):
/*jshint -W069 */
/*Disable Warning Justification:
Using bracket notation so Google Closure Compiler
ADVANCED_OPTIMIZATIONS will keep the original property names. */
obj['prop1'] ='foo';
obj['prop2'] ='bar';
/*jshint +W069 */
I assume you are asking about Dreamweaver or another editor.
Dreamweaver
You may go to Edit -> Preferences -> Linting
Select JS in the dropdown and hit Edit & Apply changes
Find
"sub": false,
and change that to true. Save the file and that notice will disappear.
If you have OTHER Linting things you wish to edit, you can find a helpful list of them all at https://jshint.com/docs/options/
Starting off using brackets as a text editor to write javascript code, kindly note I'm a beginner, and I'm getting weird errors when I write my code like unexpected console statement when I use console.log() or name is not defined if I declare a variable called name. How can I disable that feature or edit its code to fix these messages.
Edit:
What i wrote:
var name = "john";
var age = 26;
console.log(age)
var job,ismarried;
ismarried = true;
I'm getting xs sign near my lines although the age is showing in chrome normally so the issue isn't with that very simple code it's with the text editor and I don't understand how to fix it.
My instructor's answer:
These errors are probably related to JSLint and/or ESLint. These are tools used in Brackets to scan your code for bugs.You can also disable JSLint. To do that: Go to Brackets > File > Extension Manager > Default > Disable ESLint and JSLint.
for error like "unexpected console statement [no-console]" in brackets
Click on "Debug" in on your toolbar.
In the dropdown, click on "Open Preferences File".
and add below line in the brackets.json file
"language": {
"javascript": {
"linting.prefer": ["JSHint"],
"linting.usePreferredOnly": true
}
}
link for the same :
https://the-sourceterous.ghost.io/brackets-editor-disable-jslint-and-use-jshint-instead-2/
I have been unable to find any reference to this statement in any book, manual, or site. As far as I can tell, it functions exactly as a // comment. For example:
console.log("1");
--> console.log("2");
console.log("3");
will print
1
3
What I'm curious about is exactly what the difference between --> and // is, if any exists, and also why --> seems to completely absent from all the JavaScript references I've seen - the only reason I found out about it at all was because I accidentally typed it into Adobe Dreamweaver, and it was highlighted as a comment. Thanks!
Edit: Here is a functional jsFiddle demonstrating the behavior.
Edit 2: I've tested further, and I've discovered a few things.
This only works if there are exactly two dashes. -> and ---> will throw errors.
This only works with a "greater than" symbol. --< will throw an error.
This will not work in the middle of or at the end of a line. console.log("1"); --> console.log("2"); will throw an error.
My guess is that the JavaScript engine, forgiving as always, is silently ignoring the line because it looks like the end of an HTML comment (<!-- -->). JavaScript inlined in HTML has historically been wrapped in an HTML comment so that browsers that don't support JavaScript would not try to parse it.
Edit:
I've done some research, and this is indeed the case.
From V8's scanner.cc:
If there is an HTML comment end '-->' at the beginning of a
line (with only whitespace in front of it), we treat the rest
of the line as a comment. This is in line with the way
SpiderMonkey handles it.
From Rhino's Comment.java:
JavaScript effectively has five comment types:
// line comments
/* block comments */
/** jsdoc comments */
<!-- html-open line comments
^\s*--> html-close line comments
The first three should be familiar to Java programmers. JsDoc comments
are really just block comments with some conventions about the formatting
within the comment delimiters. Line and block comments are described in the
Ecma-262 specification.
Note that the --> comment is not part of the Ecma-262 specification.
This is not a comment. If you see it as a comment inside of code, then its probably showing as some kind of hanging chad HTML comment instead of the normal "//".
What's happening in this case is you are comparing using the greater than and then subtracting 1. Here are some examples...
var x = 3; var y = 3; console.log(x --> y);
false and x is now 2
If you place the normal comment characters "//", you'll get a syntax error (which you should)
The reason this is working as a comment is because it is returning as undefined. This is not safe to use as a comment. Oddly enough, it works fine in Chrome and you can throw all kinds of characters at it if you start the line with "-->".
--> something for nothing ~!####%$#%^$&%^&*()_+_=-=[]\];'\||?>;';;; alert('test'),,143187132458
However, within IE 11, it is always a syntax error. Very cool find
I have some big set of different javascript-snippets (several thousands), and some of them have some stupid errors in syntax (like unmatching braces/quotes, HTML inside javascript, typos in variable names).
I need a simple way to check JS syntax. I've tried JSLint but it send too many warnings about style, way of variable definitions, etc. (even if i turn off all flags). I don't need to find out style problems, or improve javascript quality, i just need to find obvious syntax errors. Of course i can simply check it in browser/browser console, but i need to do it automatically as the number of that snippets is big.
Add:
JSLint/JSHint reports a lot of problems in the lines that are not 'beauty' but working (i.e. have some potential problems), and can't see the real problems, where the normal compiler will simply report syntax error and stop execution. For example, try to JSLint that code, which has syntax errors on line 4 (unmatched quotes), line 6 (comma required), and line 9 (unexpected <script>).
document.write('something');
a = 0;
if (window.location == 'http://google.com') a = 1;
document.write("aaa='andh"+a+"eded"');
a = {
something: ['a']
something2: ['a']
};
<script>
a = 1;
You could try JSHint, which is less verbose.
Just in case anyone is still looking you could try Esprima,
It only checks syntax, nothing else.
I've found that SpiderMonkey has ability to compile script without executing it, and if compilation failed - it prints error.
So i just created small wrapper for SpiderMonkey
sub checkjs {
my $js = shift;
my ( $js_fh, $js_tmpfile ) = File::Temp::tempfile( 'XXXXXXXXXXXX', EXLOCK => 0, UNLINK => 1, TMPDIR => 1 );
$| = 1;
print $js_fh $js;
close $js_fh;
return qx(js -C -f $js_tmpfile 2>&1);
}
And javascriptlint.com also deals very good in my case. (Thanks to #rajeshkakawat).
Lots of options if you have an exhaustive list of the JSLint errors you do want to capture.
JSLint's code is actually quite good and fairly easy to understand (I'm assuming you already know JavaScript fairly well from your question). You could hack it to only check what you want and to continue no matter how many errors it finds.
You could also write something quickly in Node.js to use JSLint as-is to check every file/snippet quickly and output only those errors you care about.
Just use node --check filename
Semantic Designs' (my company) JavaScript formatter read JS files and formats them. You don't want the formatting part.
To read the files it will format, it uses a full JavaScript parser, which does a complete syntax check (even inside regular expressions). If you run it and simply ignore the formatted result, you get a syntax checker.
You can give it big list of files and it will format all of them. You could use this to batch-check your large set. (If there are any syntax errors, it returns a nonzero error status to a shell).
Is there an option to and/or how do I suppress errors like the following?
175,14:['tracker'] is better written in dot notation.
If it's a feature and not a bug, place this at the top of your file.
/*jshint sub:true*/
If it's a bug, you should refactor your code
foo['tracker'] = bar // from this...
foo.tracker = bar; // to this!
Good post on the reasons here: https://stackoverflow.com/a/2001410/94668
As suggested by: #ThorSummoner you can use below in your .jshintrc file
"sub": true
In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax. The identifier of this warning is W069.
This means you can tell JSHint to not issue this warning with the /*jshint -W069 */ directive.
You can even wrap several lines of code and then reenable the warning as the example below (with a note to future you why it was a good idea):
/*jshint -W069 */
/*Disable Warning Justification:
Using bracket notation so Google Closure Compiler
ADVANCED_OPTIMIZATIONS will keep the original property names. */
obj['prop1'] ='foo';
obj['prop2'] ='bar';
/*jshint +W069 */
I assume you are asking about Dreamweaver or another editor.
Dreamweaver
You may go to Edit -> Preferences -> Linting
Select JS in the dropdown and hit Edit & Apply changes
Find
"sub": false,
and change that to true. Save the file and that notice will disappear.
If you have OTHER Linting things you wish to edit, you can find a helpful list of them all at https://jshint.com/docs/options/