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

Reply via email to