| Re: [platform-ui-dev] Enhanced extensibility for the default text editor in Eclipse |
|
Hi Stefan, hi Tom, hi all,
On 07/05/2016 08:39 AM, Tom Schindl wrote: That's a good idea. However at the moment, our work with Sopot is still a level too low, we don't have a working TextMate nor Language-Server based contributor to the proposed extension points. But once we start to have actual contributors, using those to define associations is definitely something users will like.b) I would at startup look at all the lexical highlightings available and register this new CodeEditor for those suffixes/content-types - we need content-types as well because there are languages eg Bazel who have no suffix I gave parts of opinions as an answer to Dirk on that thread, on June 27th.c) I would implement all this stuff without extension points but pure Java and DI (where DI strips of all the OSGi-Dependencies) and in a new bundle / set of bundles I have some questions about DS: how easy are they to use for the regular Eclipse RCP/plugin dev compared to DS? Extension points provide documentation and good inference in the tools to use them well. Does DS provides this? That's most likely going to happen for specific extension (grammars or language server for example) which could have a "core" and "ui" part.d) I would split the code similar to eclipse.text and jface.text where we have a UI toolkit neutral part and as a second layer the presentation of the informations in an SWT UI Once we have extension points actually working for complex use-case (the ones in the proposal are very basic and miss some power regarding activation, priorities and others things yet to unveil), then implementing this should be simple. At least extension points must be designed to make this kind of thing simple to implement.e) I would use TextMate as the fall-back grammer and add a simple grammer language who is closer to the workings of eclipse.text / jface.text |