Ahh, right. Yes, this is because the command-line interface uses some pretty simple rules (bracket counting) to tell when a line is ready to be executed. It doesn't work in node.js either BTW :)

To be honest I'm not sure if we should fix this as IMO it'll trip up way more users than it helps.

Having said that, if you write code on the right, the Web IDE should somehow make it work (or should at the very least warn you that it won't work). At the moment, if you do:

function meh() {
  foo
    .bar()
    .baz()
    .quux();
}

then it will work (because of the bracket counting), but if you even do:

function meh() 
{
}

Then it'll fail - which IMO is quite a big issue.

Agreed... "fixing" it would break the command-line interface. I hadn't actually tried it through the interactive Node.js interface, but by loading via a file.

Maybe a solution would be an command similar to echo(0) (eg. wait_for_eof('FOO')) used by the IDE to instruct the interpreter to wait for a EOF token for execution rather than using bracket counting... the left-hand-side would act as before, but the upload on the right would wrapper the code in what amounts to a HEREDOC block. Or, would automatically wrappering the entire right-hand-side of the IDE in a { ... }; block do it?

This is literally what semi-colons are for—coupled with ASI they will always mark the end of an Expression, ExpressionStatement, VariableStatement, ContinueStatement, ReturnStatement, BreakStatement, ThrowStatement, DebuggerStatement and do...while.

@rwaldron And that's why we love them :-) Unfortunately, requiring them for immediate evaluations at the command-line would be a bit tedious for some. However, I can't see any reason why loaded files (in the IDE editor) and the command-line can't be treated with slightly different rules: the editor could require semicolons, whereas the command-line could use the simple rules (bracket counting) to guess at complete expressions as well.

I agree a combination of bracket counting and semi-colons should be sufficient.

The problem with automatically wrapping the code in { } is that Espruino has to have space to store all the code before execution. Sending it a bit at a time really helps.

If the editor could detect a statement that was spread over multiple lines then I guess it could wrap just that statement though?

What about uglifying JS code before it's sent to the board?

edit

This is what the original code example looks like after being run through uglify.js:

var foo={bar:function(){return console.log("bar"),this}};foo.bar(),foo.bar(),foo.bar(),foo.bar();

• Old version: 315 characters
• New version: 97 characters
• Saved: 218 (result is 30.7% of original)

This is practice is ubiquitous in web development, why not extend to Espruino?

The Web IDE can already minify the code. The issue is really that when errors are reported, it'll be pretty hard to trace them back to the original code.

Detecting just the cases of split lines and fixing them would be pretty awesome though. Is there some tool that creates a syntax tree of JS code that can be splatted back out into the originally formatted JS? If so, fixing newlines should be trivial.

UglifyJS lets you do that, IIRC.

On 31/01/2014, at 17:13, Gordon Williams wrote:

The Web IDE can already minify the code. The issue is really that when errors are reported, it'll be pretty hard to trace them back to the original code.

Detecting just the cases of split lines and fixing them would be pretty awesome though. Is there some tool that creates a syntax tree of JS code that can be splatted back out into the originally formatted JS? If so, fixing newlines should be trivial.

—
Reply to this email directly or view it on GitHub.

There was a bug in the Web IDE already:

espruino/EspruinoWebIDE#22

and it's been noted in the forum:

http://forum.espruino.com/conversations/625

I'm inclined to just wrap everything in {..} as @tomgidden suggested (but make it an option that can be turned off by people who may find out they don't have enough RAM to load everything in one go)

Web IDE now copes with common cases of if/for/while/= etc, but I forgot about this one. Looks like it actually needs a less complicated and more general solution:

• Newlines between tokens not separated with ';' when the brackets are all matched
• But not newlines after function X() { ... } (to ensure that functions are executed as they are written)

Can anyone think of anything else that would help? I've modified Espruino so that Alt-Enter allows you to add a newline even if brackets are all matched, so the Web IDE just takes advantage of that now.

Think this is sorted now