On Mon, Mar 14, 2016 at 12:00 PM, Gorkem Ercan <gorkem.er...@gmail.com> wrote:
> > > On 14 Mar 2016, at 11:33, Doug Schaefer wrote: > > Thanks Michael. I guess I'm still confused. Max mentioned that JSDT was >> using Orion, but I haven't seen much evidence of that. >> > > We are not using Orion, we use the same bits as Orion for instance our > new parser is esprima 2.7.2 and we are looking into using eslint and > tern.js but these are likely to happen next year. > > I highly encourage >> you do that (and by extension my QML work does that) to leverage as much >> of >> the expertise on the Orion project as possible, especially as they work to >> make their bits more consumable by other IDEs. >> >> Yes, Max mentioned that too but I am looking at the docs and I can not > find > something like a javascript language service, which was my expectation from > the word of mouth. I would appreciate if someone can point me in the right > direction. > It came out of a conversation I had with Steve Northover at EclipseCon. This is for Orion 12 I believe. They are building an integration that can be used with Sublime, but are doing so that any IDE could leverage. At the end of the day, Orion will be a collection of npm modules. Very interesting idea. BTW, Sublime is Eclipse's biggest competitor in the web space from what I see. An Orion integration with Sublime raises the bar even higher. > > > [1] https://wiki.eclipse.org/Orion/Documentation/Developer_Guide > > > > Doug. >> >> On Mon, Mar 14, 2016 at 11:26 AM, Michael Rennie < >> michael_ren...@ca.ibm.com> >> wrote: >> >> In Orion, we have a modified version of Esprima (its a bit old now, >>> version 2.0), that has more tolerance in it than the stock Esprima does. >>> It >>> might provide the level of recovery you are looking for. >>> >>> Our recovery is done in a few ways: >>> >>> 1. we catch and record all exceptions, to make it far less 'throwy' >>> 2. we perform node fill-ins when an exception would leave the AST is bad >>> state >>> 3. in some cases we rewind and try again based on state / tokens / and >>> line endings >>> >>> Our version can be found here: >>> >>> >>> >>> http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.javascript/web/esprima/esprima.js >>> >>> The tests we run on it (to give an idea of the kinds of things we can >>> recover from): >>> >>> >>> >>> http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.javascript/web/js-tests/javascript/esprimaTolerantTests.js >>> >>> And lastly, the bug for us to upgrade to the latest version of Esprima: >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=473765 >>> >>> Michael Rennie >>> >>> >>> >>> ----- Original message ----- >>> From: Eugene Melekhov <e...@mail.ru> >>> Sent by: wtp-dev-boun...@eclipse.org >>> To: "General discussion of project-wide or architectural issues." < >>> wtp-dev@eclipse.org> >>> Cc: >>> Subject: Re: [wtp-dev] JSDT Parser >>> Date: Sat, Mar 12, 2016 10:31 AM >>> >>> Angelo, >>> >>> Yes, sure, I used that option. The problem is that esprima actually >>> throws >>> a lot of syntax exceptions: >>> >>> grep -c throwUnexpectedToken esprima.js >>> 56 >>> grep -c tolerateUnexpectedToken esprima.js >>> 29 >>> >>> That means that in 2/3 error cases it throws exception and tolerate only >>> 1/3. Shift meanwhile doesn't throws exceptions >>> in "Early Error" cases like this 0=0, which is tolerated by esprima. I >>> have a suspicion that most of esprima >>> "tolerated errors" are from that "Early Error" category, which means that >>> in fact Shift behaves like esprima :-) >>> >>> I thought that it would be interesting to compare shift and esprima >>> behavior on large enough set of erroneous code >>> fragments. It might happen that they are very close actually :-) >>> >>> >>> I'm not a big expert with esprima, but do you use tolerant option like >>>> >>> explained at http://esprima.org/doc/ ? >>> >>> 2016-03-12 10:25 GMT+01:00 Eugene Melekhov <e...@mail.ru>: >>>> >>> >>> Angelo, >>>> >>>> One more thing about parser tolerance. esprima for example throws an >>>> >>> exception parsing this "relatively simple" >>> >>>> declarations: >>>> >>>> //function foo(a, b {} >>>> >>>> //function foo(a, b, c,) {} >>>> >>>> //function foo(a, b, {} {} >>>> >>>> >>>> Yes sure, but it seems that Shift doesn't support tolerant parser >>>>> >>>> which is very required for a JS editor. See >>> https://github.com/shapesecurity/shift-java/issues/93 >>> >>>> >>>> >>>> >>>> -- >>>> Eugene Melekhov >>>> >>>> _______________________________________________ >>>> wtp-dev mailing list >>>> wtp-dev@eclipse.org >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> >>> from this list, visit >>> >>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>>> >>>> >>> >>> >>> >>> -- >>> Eugene Melekhov >>> >>> _______________________________________________ >>> wtp-dev mailing list >>> wtp-dev@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>> >>> >>> >>> _______________________________________________ >>> wtp-dev mailing list >>> wtp-dev@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>> >>> _______________________________________________ >> wtp-dev mailing list >> wtp-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/wtp-dev >> > _______________________________________________ > wtp-dev mailing list > wtp-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/wtp-dev >
_______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/wtp-dev