> 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.
I have created a few wiki pages with information about our experimental API (emphasis on experimental). It is not provided as a service, but instead, the _javascript_ tools from Orion are built into a UMD library that can be consumed directly outside of Orion.
Have a look at the following pages:
Michael Rennie
----- Original message -----
From: "Gorkem Ercan" <gorkem.ercan@xxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
To: "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [wtp-dev] JSDT Parser
Date: Mon, Mar 14, 2016 11:03 AM
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.
[1] https://wiki.eclipse.org/Orion/Documentation/Developer_Guide
> Doug.
>
> On Mon, Mar 14, 2016 at 11:26 AM, Michael Rennie
> <Michael_Rennie@xxxxxxxxxx>
> 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 <emvv@xxxxxxx>
>> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>> To: "General discussion of project-wide or architectural issues." <
>> wtp-dev@xxxxxxxxxxx>
>> 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 <emvv@xxxxxxx>:
>>
>>> 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@xxxxxxxxxxx
>>> 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@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
