[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [wtp-dev] [epp-dev] Neon RC2 packages
|
On 30 May 2016, at 11:26, Angelo zerr wrote:
but my first choice is to use a language server and remove
implementation
out of JSDT.
Gorkem, you mean to do like typescript.java? If it that, I will be
glad to
do contribution if you are agree.
Yes, the same approach but some differences on the implementation. We
would like to standardize on a
language server API that would allow Eclipse IDE, Eclipse Che, VSCode
and others to share these services.
Currently, we are using [1] as the starting point.
Ideally, I would like to see a generic language editor that can host any
language and integrate to these services.
Mickael is looking at possibilities on that. Without knowing the
implementation details, I think we can discuss bringing
in typescript.java but we need the legal approvals for typescript and
node.js before we can do anything.
[1] https://github.com/Microsoft/vscode-languageserver-protocol
—
Gorkem
2016-05-30 17:20 GMT+02:00 Gorkem Ercan <gorkem.ercan@xxxxxxxxx>:
_____________________________
From: Ilya Buziuk <ibuziuk@xxxxxxxxxx>
Sent: Monday, May 30, 2016 7:28 AM
Subject: Re: [wtp-dev] Fwd: [epp-dev] Neon RC2 packages
To: General discussion of project-wide or architectural issues. <
wtp-dev@xxxxxxxxxxx>
On Mon, May 30, 2016 at 11:17 AM, Mickael Istria <mistria@xxxxxxxxxx>
wrote:
Thanks for the info Eugene.
About IP and license, would it be possible for JSDT to embed such a
TS
server to generate an AST-ish that we could use for such
navigation/refactoring operations?
As I recall, CQ for shipping node is already opened but not yet
approved.
I guess, if it will be approved the next logical step will be
opening CQ
for using tsserver. Anyway, It looks like support of language
services in
JSDT is not going to happen early than Oxygen. For Neon.1 the plan
is to
replace esprima with closure compiler, while still using DOM AST
model
(converting from Closure's Internal Representation will be required).
We already have a CQ for typescript language services. If we can get
approval for both node.js and typescript we do plan to move JSDT
services
to use a language server.
Looking at the current state of JSDT, it seems like most features
depending on AST are broken. So there are 2 ways to go AFAIK:
dropping the
legacy AST and using another model (such as the TS one) directly, or
having
the parsers populating an AST. I feel like the first one is more
sustainable and
We are still producing AST, the problems are mostly due to features
depending on the internal data or behaviour of the old parser. We can
probably move and fix some of them by using AST but my first choice
is to
use a language server and remove implementation out of JSDT.
requires more effort.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
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