Community
Participate
Working Groups
More and more languages are shipped with there tools counterpart acting as a language service. Instead of creating editors taking care of parsing and so on, we could imagine having the default Text editor in Eclipse enriched by features provided by such services.
This is an umbrella bug for several big tasks.
See also: https://github.com/eclipselabs/eclipse-language-service/blob/master/adoc/language-server.adoc
This would be a new editor in the platform. We should revive the 'org.eclipse.ltk.ui' plug-in for this. Requirement for this is to have at least one protocol and one registry that provides the services.
(In reply to Dani Megert from comment #3) > This would be a new editor in the platform. What are the blockers in current Text Editor in Platform that make it wrong to add support for extension-based coloration/completion/hover? It already supports pretty well hyperlinks via extension, so the suggested pattern (of adding extensions) is already implemented to some pieces of the current Text Editor. If we manage to implement it or at least some parts of it without breaking API (that's a challenge, but might be achievable), what's the benefit of working on another editor?
(In reply to Mickael Istria from comment #4) > (In reply to Dani Megert from comment #3) > > This would be a new editor in the platform. > > What are the blockers in current Text Editor in Platform that make it wrong > to add support for extension-based coloration/completion/hover? It already > supports pretty well hyperlinks via extension, so the suggested pattern (of > adding extensions) is already implemented to some pieces of the current Text > Editor. If we manage to implement it or at least some parts of it without > breaking API (that's a challenge, but might be achievable), what's the > benefit of working on another editor? We need to have a pure Text editor and a generic Code editor. This allows to provide the new functionality in a completely separate plug-in (e.g. org.eclipse.ltk.ui), which RCP apps can simply ignore. I've also discussed this with Max and he completely agrees.
So the "Code Editor" would become the default editor for end-users of Eclipse IDE? Also, even with extension *points* in the Text Editor, it doesn't change much for RCP apps. As I imagine it, the actual features provided by language service or whatever would be in external plugin (ltk for example), but the extension points could be in the Text Editor. Apart from the difficulty in implementing it without breaking anything, I do not see what's the issue with adding extension point to Text Editor directly. Am I missing something? I can easily imagine some non-code editor who'd be glad to take advantage of interaction for coloration/completion/hover. So IMO, making a distinction between Text and Code isn't very meaningful.
(In reply to Mickael Istria from comment #6) > So the "Code Editor" would become the default editor for end-users of > Eclipse IDE? Probably. > Also, even with extension *points* in the Text Editor, it doesn't change > much for RCP apps. As I imagine it, the actual features provided by language > service or whatever would be in external plugin (ltk for example), but the > extension points could be in the Text Editor. Apart from the difficulty in > implementing it without breaking anything, I do not see what's the issue > "Apart from the difficulty" That's the issue. We can either ship a new code editor in the platform, or if you think this is not useful, you can ship it separately via Marketplace. I don't want to touch the Text Editor.
We should aim to have a good implementation that is widely accepted. A good starting point is to provide information. I think we need pointers to: (a)- Existing resources and usage examples. i.e.: TextEditor and CodeEditor samples (b)- Defined or proposed interfaces, i.e. Interface explaining minimum contract of work for code completion / (LTK) refactoring. (c)- Discussions about critical points, i.e. (c.1) which lexer should we use to highlight, (c.2) which interface use to pass code suggestions (c.3) how to implement the language server, etc.. For the LTK, I found a few references: #1 and #2 and #3. Are this references ok? - are them still actual? Do we have some further specifications or partial implementation ? I'm sure if we prepare properly the ground, soon we'll have several people interested in revamping editors. [#1] https://eclipse.org/articles/Article-LTK/ltk.html [#2] http://www.eclipsecon.org/2005/presentations/EclipseCon2005_5.1Maetzel.pdf [#3] https://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html
(In reply to Patrik Suzzi from comment #8) > For the LTK, I found a few references: #1 and #2 and #3. > Are this references ok? - are them still actual? Didn't check them, but some of that is already implemented, e.g. in the core LTK layer.
I am really sorry but I do not understand why you want to spend so much efforts on this. There is no ready to use code server which you can simply reuse by providing front end for it which will be comparable in features and functionality with existing editors for major languages. You probably know that Eclipse Che uses JDT but not some "code server". There should be a reason for this. Right? Converting you own editors to this is another huge effort which will not give Eclipse IDE any benefits and I do not believe it will happen. Relying on 3-rd party to provide state of the art code server plugins which will be better compared to existing is possibility with quite low probability of success (IMHO). I mean that there are major and useful features requested by users years ago which are still not addressed. And for me as for person who uses Eclipse IDE it is a bit sad to see that instead of addressing some of these long standing major requests efforts are put into other things. That does not mean that features discussed in this defect are bad. I am saying that my personal point of view is that vast majority of Eclipse IDE users would like to see other things addressed instead.
(In reply to Serhiy from comment #10) > I am really sorry but I do not understand why you want to spend so much > efforts on this. There is no ready to use code server which you can simply > reuse by providing front end for it which will be comparable in features and > functionality with existing editors for major languages.You probably know > that Eclipse Che uses JDT but not some "code server". There should be a > reason for this. Right? There are many successful products and experiments going on which implement a client for such code server. Existing one include tsserver, tern.java. Some other interesting one to consider would be OmniSharp to have decent C# in Eclipse with less effort. And, of course, the VSCode language server and protocol which may be a good factorization of all those. So overall, there are good reasons to try it, both in Eclipse Che and Eclipse IDE, and many Eclipse contributors are convinced about the value of at least investigating that direction. > Converting you own editors to this is another huge effort which will not give Eclipse IDE any benefits I believe we all agree with that, and converting existing editors is not in the scope of that change. This change is more targeting upcoming editors (or upcoming features in existing editors). > Relying on 3-rd party to provide state of the art code server > plugins which will be better compared to existing is possibility with quite > low probability of success (IMHO). Look at how various other tools have implemented TypeScript support relying on tsserver. That's IMHO a factor of highly probably success for Eclipse IDE.
Mickael, Don't get me wrong. I am not saying that this is a bad idea. There are hundreds of ideas and most of them are good for somebody. Different people have different needs and this defines what is good for them. I was just saying that as existing Eclipse IDE user I would selfishly welcome other features compared to this one. I was hoping that improvements to such core components as let's say JDT will get more attention. My motivation is very pragmatic - there are existing editors for all major programming languages. So why new one? Who will benefit from this? There are multiple plugins for TypeScript. And there is even one which already uses tsserver: https://github.com/angelozerr/typescript.java/wiki/Why-TypeScript-IDE I guess it is possible to build some 3-rd party plugin based on https://github.com/angelozerr/typescript.java to extend it to other languages. Having C# in Eclipse is ok (if it is free). But I can bet that not many existing Eclipse users need this and C# developer will still continue to use Visual Studio. So why would Eclipse users need C# more compared to let's say Android tools, or better and faster index (or many other things)? I am not saying that somebody has to work on this. But I still think that majority of regular Eclipse users will want such feature more. Editors for new and exotic languages. Again that's ok if it's "free" and if it's done after most major requests for existing languages are implemented. The situation is that even for JDT there are tons of really major and needed features which are not yet implemented after they were requested for years. So personally I do not understand why C# support or yet another TypeScript editor should be added to Eclipse in situation when there are major long standing requests even for JDT which are still not addressed. Please don't get me wrong. I do not want to offend anyone. And I realize that in open source project nobody owes anything to me or other users. All I tried to say that from my point of view I would love to have issues and improvements in JDT and other existing tools addressed first instead of having new generic code editor. And for me as a regular Eclipse user it is sad to read that "many Eclipse contributors are convinced about the value" of new generic code editor at the same time when, for example, there is reported in 2014 issue that in JDT content assist functionality still has no support for lambda expression completions. And it is quite sad for me to realize there is a chance that Eclipse can get C# support before having that 2014 issue with lambda support fixed. Serhiy
Serhiy, this ticket is to track the technical part of that proposal. Whether you find it relevant or not is not really the topic of this ticket. I suggest you post your concern on more general media such as the ide-dev@eclipse.org or platform-ui-dev@eclipse.org mailing-lists.
As the LSP4J contains the Java support for LSP, and the current Eclipse/LSP integration very heavily relies on LSP4J, I believe LSP4J would be the best candidate to host that work. @Sven @Miro: Would you agree to have LSP4J hosting the eclipse integration currently at https://github.com/eclipselabs/eclipse-language-service/ ?
(In reply to Mickael Istria from comment #14) > As the LSP4J contains the Java support for LSP, and the current Eclipse/LSP > integration very heavily relies on LSP4J, I believe LSP4J would be the best > candidate to host that work. > @Sven @Miro: Would you agree to have LSP4J hosting the eclipse integration > currently at https://github.com/eclipselabs/eclipse-language-service/ ? After some more consideration, the Eclipse integration will have a different set of contributors, a different schedule, use different releng tools... I'm more thinking now that it would be easier to have the Eclipse integration in another separate project, something like "LSP4E to highlight the relationship between both projects like EGit/JGit do. Has anyone any concern or recommendation about making it a separate project?
(In reply to Mickael Istria from comment #15) > (In reply to Mickael Istria from comment #14) > > As the LSP4J contains the Java support for LSP, and the current Eclipse/LSP > > integration very heavily relies on LSP4J, I believe LSP4J would be the best > > candidate to host that work. > > @Sven @Miro: Would you agree to have LSP4J hosting the eclipse integration > > currently at https://github.com/eclipselabs/eclipse-language-service/ ? > > After some more consideration, the Eclipse integration will have a different > set of contributors, a different schedule, use different releng tools... > I'm more thinking now that it would be easier to have the Eclipse > integration in another separate project, something like "LSP4E to highlight > the relationship between both projects like EGit/JGit do. > Has anyone any concern or recommendation about making it a separate project? I think it's a good idea to have a separate project. Maybe under 'Technology', like EGit.
(In reply to Mickael Istria from comment #14) > As the LSP4J contains the Java support for LSP, and the current Eclipse/LSP > integration very heavily relies on LSP4J, I believe LSP4J would be the best > candidate to host that work. > @Sven @Miro: Would you agree to have LSP4J hosting the eclipse integration > currently at https://github.com/eclipselabs/eclipse-language-service/ ? I'm fine with both options: including the Eclipse integration in LSP4J or having a separate project LSP4E. If we go for a common project we should use two separate repositories, so it wouldn't be any problem to have a different set of developers and a different development environment. The common approach could help to give both features greater visibility. Another reason for it could be to minimize administrational work.
(In reply to Miro Spoenemann from comment #17) > I'm fine with both options: including the Eclipse integration in LSP4J or > having a separate project LSP4E. If we go for a common project we should use > two separate repositories, so it wouldn't be any problem to have a different > set of developers and a different development environment. The common > approach could help to give both features greater visibility. Another reason > for it could be to minimize administrational work. If we also expect both "components" to have different schedules and sets of committers, it seems that having separate projects is way to more easily distribute administration. It seems to me that we should follow the EGit/JGit example there, which has been pretty successful both for JGit and EGit.
Project proposal is live at https://projects.eclipse.org/proposals/eclipse-lsp4e
This is covered by a separate project, that's been approved at Eclipse.org and that's going to be provisioned soon. See bug 507189 for progress. *** This bug has been marked as a duplicate of bug 507189 ***
