Mikael,
> Concerning the A0 character - I'm not expert on what is and what isn't valid
> white space in JavaScript but I'll try to pass this to Eclipse JSDT team.
> Nevertheless, during my nearly 40 years experience in software development
> this is the first time I see someone using no-breaking space in program
> code. But it's never too late to learn something new.
>
I'm not saying it's recommendable, and in fact we decided to avoid these
characters in the framework. With the apps, we are less strict. The
point is there are roughly 16-18 characters in Unicode's "Separator,
Space" (Zs) category (where +U00A0 belongs to) which are *explicitly*
allowed by the Ecma262 spec, so I take it that tools supporting
Javascript should also support those characters. Some editors insert
them, others don't, and even others choke on them, so what should we
do?! I know it's not your fault, but at one point we have to push back
flaws where they belong.
> Concerning the syntax errors, again I'm not an expert but if I replace the
> identifier "infinity" by "pinfinity" in the code then that error disappear.
> Obviously Eclipse JSDT treats "infinity" as reserved word. I'll try to pass
> this and the other "syntax errors" to the JSDT team as well.
>
In fact the reserved word is *Infinity* (capitalized!), and JS is
case-sensitive, so "infinity" is a completely innocent identifier. And
even it it *were* reserved, you could *still* use it in your code
(thereby shadowing the original binding). Again, maybe not recommendable
but valid still.
> Concerning the template files, AFAICS, these files become valid JavaScript
> _after_ you replace the %{name} macros by adequate strings. Before
> replacement these files aren't valid JavaScript, AFAICS. The remedy would be
> to name these files not ending in ".js" but in e.g. ".js_templ". Then they
> wouldn't be interpreted by JSDT at all.
>
You are right, they are mostly legal JS, with some non-legal stuff
thrown in. And to even extend this, we have Python templates where the
same applies! The point here is, they have their extension for a reason,
namely, that we have tools and procedures in place that depend on the
file extension exhibiting what the file is "mostly" about, so e.g. when
we do mass-corrections by file type, these files get included. I don't
see why we should abandon all of that, just to make JSDT look less, uhm,
uptight. (Again, I know it's not your fault).
> In Eclipse JSDT workspace I need only the framework sources which are used
> for real-time syntax checking and context suggestions. I can remove
> application, component, and tool dirs. Therefore only the above syntax
> errors in framework files need some resolution.
>
Fine, that'll get you rid of all the "invalid character" cases, and
some, no wait, all of the template issues. You're left with four syntax
issues. I cannot speak for the maintainers of framework classes, and
whether they are likely to give up on the "infinity" identifier. But I
can tell you that JSDT is simply botching things up when it complaints
about a double quote not properly closed - in a *regexp*! Or complaining
about comma-chained expressions in a "while" conditional. If you hope
for amendments here, I don't see that happen on our side.
What are you trying to achieve, anyway? Are you working for Eclipse? Why
did Alex, who bothered to install a JSDT into his Eclipse, not get any
of your issues?
T.
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
