Thomas,
> 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?
I'm not working for Eclipse but I'm using it as my main IDE for all kinds of
developments. I've been using it for many years now, long before it got the
name "Eclipse" and went open source.
As I described in my other message, I'm trying to establish a developer
friendly development environment for projects involving both rich web client
(e.g. qooxdoo) and advanced server software (e.g. EJB, servlets, JSP, and
other services). One needs to source-code debug both the client and the
server part within one and the same debugging session. Eclipse IDE for Java
EE Developers (http://www.eclipse.org/downloads/) gives you such an
environment for the server part. Eclipse JSDT project aims to give you the
same for client parts. I'm investigating whether it is possible to combine
both during one session. Currently I'm working at user level but I could
think of working at Eclipse plug-in level if I see the need and reasonably
feasible solution.
I don't know why Alex did not get the same errors as I did. I installed
Eclipse ATF containing JSDT into Eclipse EE and then imported qooxdoo into a
new JavaScript project. If you already have a project then your need to
enable JSDT for it by right click on it in Project Explorer, then choose
Configure/Add JavaScript Support on popup menu.
You are quite right; Eclipse JSDT is not entirely mature yet. It is a part
of Eclipse ATF which is at 0.3.0 version level. I'll try to pass my
observations here to the team.
Thanks/Mikael
------------------------------------------------------------------------------
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
