Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Code editors in the Eclipse (IDE)

Hi Tom,

comments inline...

2016-06-15 13:42 GMT+02:00 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
The first and most important things needed are:
- syntax highlight (lexical!)
- block detection (for curly brace language this means matching
  {},[],() pairs) used for highlighting and code-folding (although I
  don't really see code-folding as an important feature at all)

I like to separate this between 
 - services that can be done generically / based on "simple" configuration and
 - services that need an AST and workspace/project information
The first are executed directly in the editor while the latter need requests to some language engine (or server).

For editor features there are more that come to mind like e.g. auto editing and toggle comment.

There are solutions available for that already:
- Angelo has TextMate support
- LiClipse has TextMate support & its custom spec format
- e(fx)clipse has its own format (who misses code folding as of today)

Although I'm not against having TextMate I repeat that the most
important thing for lexical highlighting is speed hence I'm not sure the
TextMate route is the best way.

Could you elaborate on the performance issues you expect or have faced with interpreting the TextMate grammars in Eclipse?

An important point in all this is to use something that is widely supported. 
There are thousands of TextMate Grammars on github and that is because they are directly supported by many editors.
I would like to achieve the same for other features, hence my push for a common language server protocol.

Complex requirements

Once we have something that matches the simple requirements we can work
integrating the more complex ones who are (once more in order of
- Auto-Complete
- Error-Reporting
- Documentation Hover
- Context-Information
- Code navigation
- Semantic-Highlighting (there might be languages like DSLs where
  semantic highlighting is even more import than anything else eg CSS)

Most of those can be made possible using Language-Servers and their
protocols [1,2] (although I would not directly built in the support for
a specific protocol into Eclipse).

Why not?
What if we could help making one of the existing protocols the defacto-standard of language server protocols, similar to what TextMate Grammars are for syntax highlighting.
If I were building an editor I would support that protocol first, because I will make a lot of stuff build by the community working easily. OTOH if I implement a language and want to have editor support I would implement a protocol that is supported by most popular editors.

We could of course invent yet another protocol and hope that people will implement language servers for that. But will they?
If we support e.g. what vscode has defined, it will be much simpler to get already supporting language servers working in eclipse.

Sure, a common protocol comes with compromises, but the value in leveraging the synergies is tremendous.
And of course we can always add eclipse-specific extensions to the protocol that then would or would not be supported by language servers.

That said I don't think it needs to be baked into Eclipse deeply but can be built as a plug-in. Also if there is more than one popular protocol we should support that as well, but ideally we bundle our resources on one and don't waste time on shims between all the different ones. 

Back to the top