Hi Stefan, hi Tom, hi all,
On 07/05/2016 08:39 AM, Tom Schindl wrote:
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
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.
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 gave parts of opinions as an answer to Dirk on that thread, on
June 27th.
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?
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
That's most likely going to happen for specific extension (grammars
or language server for example) which could have a "core" and "ui"
part.
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
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.
|