[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [xtext-dev] Content Assist in Xtend
|
Hi
Xtend content assist is always generated but disabled by default.
To enable it, override the IContentAssistInvocationHandler service
for your language as done in
/org.eclipse.xtext.ui.common.tests/src/org/eclipse/xtext/
testlanguages/ContentAssistTestLanguageUiConfig.java
We may want to provide a switch in the generator to tell whether you
want Xtend API or Java API in general?
I think the Xtend API is very important for acceptance specifically
for migrating oAW Xtext users, while we will always have much better
scalability and performance with the Java-based APIs. So both ways
should be equally supported.
OK, so we either generate Xtend or Java services.
Currently, I use very bad pattern in the ui.common.tests to recycle
the tests from the Java impl. I haven't introduced a service in the
generator yet, as it would collide with the Java CA. We should find
a common solution here.
Yes, why do you want to reuse AbstractProposalProvider? I thought
that most of it's implementation is dedicated to simulate
polymorphic dispatch, which in the case of Xtend is handled by Xtend
itself, isn't it?
I'ld prefer to have an XtendProposalProvider which is configured
with an Xtend file.
I'm not sure whether the Invoker abstraction is that useful.
I am already changing that...
Some more observations:
- In Xtend, dealing with a JavaMetamodel and an
EmfRegistryMetamodel for ecore in parallel causes a lot of casting
errors. You can work around that by delegating some calls to Java
to perform the casts e.g. from ecore::EObject to
org.eclipse.emf.ecore.EObject. Reordering the metamodels in the
ExecutionContext didn't help either. Maybe we find a better solution.
I see two possibilities:
1) we fix Xtend so that we don't have these problems (if possible)
2) we introduce EClasses for all the JavaAPi and translate them in
the framework
Both don't appeal to me:
1) We run the risk of changing a lot, breaking API, etc.
2) Lot of double work, even more performance overhead at runtime, as
things have to be translated. Note that the Xtend test is
significantly slower than the Java variant, even though we don't
really execute complicatd code...
Any other ideas? What would you prefer?
- Overriding a service in the configuration looks horrible compared
to the initial deifnition. Maybe we should improve the syntax here.
Heiko is taking care of the dependency injection stuff.
-
org
.eclipse
.xtext
.ui
.common
.editor
.contentassist
.impl.AbstractProposalProvider.completeAssignment(Assignment,
IContentAssistContext) sometimes produces strange method names when
the default alias is used. Someone has to investigate.
I guess, we need a bug report for this. ;-)
I'll do that.
Jan
thanks,
Sven
_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev
--
Dr. Jan Köhnlein
Senior Software Architekt
Telefon: +49 (0) 431 / 5606-337
Mobile: +49 (0) 163 / 3979 776
Telefax: +49 (0) 431 / 5606-339
http://www.itemis.de
jan.koehnlein@xxxxxxxxx
itemis AG
Schauenburgerstr. 116
24118 Kiel
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Prof. Dr. Burkhart Igel (Vors.) Stephan Grollmann,
Michael Neuhaus
