Develop Reference

Javascript charCodeAt not reading correct codes

I was trying to host a code of mine from Khan Academy on my own website.
The processing code works alright on Khan Academy. But while hosting it I am facing some issues.
The problem is - Khan Academy's processing is able to read unicode value of certain characters correctly, but when I do the same offline from the browser it gets incorrectly shown.
I think it has to do with the charCodeAt function not working correctly.
Here's my code :-
var test = "Ĭ";
println(test);
println(test.charCodeAt(0));
On Khan Academy the unicode is correctly printed as 300. Wherease my browser prints it as 196. Whats more the string is interpreted as 2 characters instead of 1 from the browser. It's size is shown as 2.
How to make the charCodeAt to work correctly.
Please note that I am making use of Processing JS and here is the code I am making use of to host a Processing Canvas :-
var sketchProc=function(processingInstance){ with (processingInstance) {
size(400, 400);
frameRate(60);
var test = "Ĭ";
var n = test.codePointAt(0);
println(n);
println(String.fromCharCode(300));
println(test.length);
}};
Thanks.

Based on the comment of AlexandrKapustin, I was able to resolve the problem.
I added the following meta tag to the html file hosting the Processing script :-
<meta charset="utf-16">

How to include more JavaScript inside Atom editor by Github?

I've been playing with snippets for Atom editor,
and see that I've learned I can include
JavaScript inside of a snippet, as my example shows.
(It inserts a TODO Comment with date)
TODO: (RAM) Fix this - 2014-11-23 20:55
HELLO
How can I include MORE JavaScript.?
For example
inside the snippet to set
var= to something
or
call a JS library
or
ask for input from user i.e. confirm();
and proceed on basis of confirm() function.
Any help would be appreciated, I looked for a long time,
but not much documentation on this. Submlime Text's snippets allowed lots of code to be inserted via Python.
Thanks
~Rob
Inside file snippets.cson
'.source.js':
'Date TODO: insert':
'prefix': 'datetd'
'body': """
TODO: (RAM) $1 - #{datetime = new Date(); datetime.getFullYear()}-#{(datetime.getMonth()+1)}-#{datetime.getDate()} #{datetime.getHours()}:#{datetime.getMinutes()}
#{"hello".toUpperCase(); }
$2
"""

Update: With the merge of atom/atom#4791, the capability of putting CoffeeScript code in CSON configuration files has been removed from Atom. The rest of the answer has been left intact for historic reference.
Actually, the syntax of the file is CoffeeScript (hence .cson as in CoffeeScript Object Notation), not JavaScript. It just so happens that you typed in JavaScript that is allowed as CoffeeScript. CoffeeScript doesn't use the var keyword, so you can assign variables like you did in your example:
datetime = new Date()
The other items, you'll probably have to get a little creative. I don't believe that the snippets package was intended to be used in this manner, which is why the lack of documentation on the "feature".

What is the difference between buffered and unbuffered code?

This documentation is confusing.
It says, unbuffered code does not output any code directly. What does that mean?
But in general, what is the difference between buffered and unbuffered code?
Would also be nice if they didn't disable copy and right click on the page too!

"Unbuffered" means that the code is executed, but the results are not sent to the output buffer.
"Buffered" also means that the code is executed, and the results are sent to the output buffer.
For example, this Jade:
.unbuffered
- 'unbuffered vs buffered'
.buffered
= 'unbuffered vs buffered'
Produces this HTML:
<div class="unbuffered">
</div>
<div class="buffered">unbuffered vs buffered
</div>

Please ignore this answer as it is incorrect as pointed out in the comments
I invite you to have a look at matty's answer instead.
From what I understand in the documentation link you shared I'd say there is a major difference:
Unbuffered code is not executed when read, but deferred (it is looks like javascript), which means that the string is post processed.
It seems that they map the string to an internal routine, that is hybrid js + templating language.
Buffered code is on the other hand executed as javascript (first it is preprocessed to escape html).
Though it seems to have a different behavior according to which code you put in there.
For example it is said that this:
p='Test' + ' concatenation'
Will result in Test concatenation
But now, you could do this:
p=(function() { return 'Does this really work ?! It seems so'; }())
It will result in Does this really work ?! It seems so.
It simply evals your code and escapes the html.

What does --> do in JavaScript?

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

Is <!-- valid javascript?

I recently had to fix a bug that manifested sometimes in Internet Explorer. The bug was that, sometimes, the parser choked on code like
<script type="text/javascript">
<!-- // comments -->
/*...*/
</script>
Which we fixed by correcting the comment.
My question is: is "<!--" valid javascript code, or not? I tried testing it with firebug, and it only says" Undefined". JSFiddle didn't faze. IE only choked on it some of the times (reloading the page in question would show up the result of the script involved).
While knowing that, for historical reasons, an HTML comment inside js could be valid depending on its exact position and the phase of the moon is indeed useful, I was more interested in answers like "var <!-- foo is valid js code, but <!-- on its own is not. Here's why:..."
I did some analysis in firebug:
var x = 2;
var y = 3;
var z = 0;
console.log(x);
console.log(y);
y<!--x;
console.log(x);
console.log(y);
z = y<! --x;
console.log(x);
console.log(y);
console.log(z);
resulting in the following:
2
3
2
3
1
3
false
The difference between the first and second tries is interesting.
I then tried
z = (y <!--x);
console.log(z);
Which failed with
SyntaxError: missing ) in parenthetical

First to answer your question on Is <!-- valid JavaScript: No, it is not, in none of the forms you gave in your question. This is because it is not valid according to the JavaScript BNF grammar which you can find here: http://tomcopeland.blogs.com/EcmaScript.html
If you are interested, here's why you do see it inside script blocks: It is the HTML comment character. You do see it very often within script tags like this:
<script>
<!--
.. JavaScript code...
// -->
</script>
The reason is that old browsers (and with "old" I mean "stone age" like Netscape 1.0) that do not even support JavaScript and would otherwise just show the code on the screen. By doing it this way those older browsers treat the JavaScript as HTML comments and do not show it. Newer browsers ignore this and just run the JavaScript.
This is how it actually works (from http://www.w3.org/TR/html401/interact/scripts.html#h-18.3.2): The JavaScript engine allows the string <!-- to occur at the start of a SCRIPT element, and ignores further characters until the end of the line. JavaScript interprets // as starting a comment extending to the end of the current line. This is needed to hide the string --> from the JavaScript parser.
Because all browsers nowadays support JavaScript (even if it is turned off) you do not need to do this anymore. It is actually bad practice to do so because of these reasons (from http://www.javascripttoolbox.com/bestpractices/#comments):
Within XHTML documents, the source will actually be hidden from all browsers and rendered useless
-- is not allowed within HTML comments, so any decrement operations in script are invalid
An even deeper explanation and all the cons and pro's can be found here: http://lachy.id.au/log/2005/05/script-comments

In older browsers, it was required to have these comments inserted because the browsers couldn't parse the javascript properly. it would try to literally parse the javascript as html which caused script execution failures.
Today, browsers don't need this.

It's not.
If you go to the standard, you'll see that a < can only exist in a RelationalExpression, which <!-- is not as it hasn't got anything on the left-hand side.

Comments in Javascript are like other C-type languages (// for single line, /* */ for blocks.