Web IDE release 0v47

@Gordon, not really complaining just expressing a bit my frustration with the Web IDE source editor: the frustration grows by the hours. There comes a point where a plain - JS agnostic - editor is preferred over a stubborn and single minded editor. I see the 'well intentions' to support writing syntactically formatted, good looking code... but many roads lead to Rome, and the road(s) are picked based on the needs.

Most bothering is when the editor creates automatically things that it then points out as warnings. As mentioned before, when typing a colon or a curly bracket 'down the line' in a line, the editor thinks I need to adjust the formatting / indentation and it creates a space-tab-mixed indentation - looks like derived from the previous line, event though the current line has already a clean, non-mixed indentation, and so has the previous line. It is anyway not clear what the indentation policy is the editor follows.

It is not good enough to derive formatting from the syntax alone, which - for most JS supporting editors - is still script and function oriented vs. object oriented. May be knowing about the provenience of the underlaying editor could be helpful to adjust and work with and around the uniquenesses / caveats.

On another note, I see the well intentions to make coders aware of things such as == and === and mistaken = (assignments) in logical expressions for ifs and consort - and indeed - the latter gave me grief in the past. But the warnings 'get at me' - and even get the editor's code validator: the validator gives up the really helpful error detection and marking just because there were warnings. I'm now moving code around so the sections I'm working on are in the beginning where 'my warning allotment' is not yet used up and the very helpful syntax error detection support still works.

I'd like to change some of the nasty JS things as well... but differences to the defacto JS standard bother me more. I hope over time things move more as they already do, and as they did for example for HTML: You may recall the approach of XHTML 1.0 (HTML 4.1 / 4.01), which failed miserably after years to get XHTML 2.0 spec out the door. It did not fail because of missing well intentions, but because history can just not be ignored: existing code base and (human) resources . The solution was to abandon the idea of radical XHTML and have a smoother migration path... and HTML5 came into being and is picking up - even with the few missing backward compatibilities. The browsers still know to handle past - not so clean - pages (may be that's why the browsers are now all that bulky / big foots / memory foot print... and I'm aware of Espruino's resources are just too limited to work under all circumstances, so a line has to be drawn. The best line is the line with the least differences that benefit maximum simplification for Espruino - most bang for the buck - $ - £ - CHF -... ;) ).

Therefore my question: what would be the easiest way to make the editor just talk (real (Espruino) JS) errors and nothing else? ...or make the editor file change time stamp sensitive, so another editor - for example, Eclipse - can be used and WEB IDE checks and informs time stamp changes with optional refresh-from-file-storage before sending to the board?.. I know that I loose much of the coding support - especially the cool board custom specific support - that just as been added. After using that great support for getting the connectivity modules for the hardware and base software modules done though, I spend most of the time in algorithms processing the data, which has nothing to do anymore with PINs, LEDs, or board specific JS, etc. and that support is just idling... and - too bad - not missed when working in another editor.

Another weird thing is that when saving a file with a different name than it was originally loaded with - like a save as... - the next save's default name will still hold on to the previous file name - and got me overwriting things - not really a surprise, because every overriding save asks (annoyingly every time) ... override or not? - even when saving with the same name. There are obviously different philosophies out there about saving with a new name and saving with the same name. A mitigation with minimal effort would be to show the file's name in-edit - which is known as the file's default safe name - somewhere in the UI, for example in the top blue bar, which now looks pretty inviting (...or empty).