Home » Modeling » TMF (Xtext) » strange behavior for navigation to elements
| strange behavior for navigation to elements [message #1500079] |
Fri, 05 December 2014 17:16  |
|
Hi
in the editor of one of my DSLs based on Xbase (2.7.3) I see a strange
behavior concerning navigation:
- F3 always correctly jumps to the declaration (for Java type
references, feature references, etc.)
- Ctrl+click on a feature reference jumps to the return (Java) type (and
holding Ctrl pressed shows two options: "Open Return Type" and "Open
Implementation", so "Open Implementation" is not the default choice, and
I don't know where "Open Return Type" comes from)
- Ctrl+click on any Java type reference does not result in any effect
(not even on the XImportSection)
The JvmModelInferrer for this language infers several Java types and
several Java methods for the corresponding DSL elements, so I might have
done something wrong with model associations in the inferrer... any
hint on what to debug for the behavior of Ctrl+click?
The odd thing is that even with an XBlockExpression like this one
val my = "foo"
println(my)
Ctrl+clicking on "my" brings to the java.lang.String; and with that
respect, I haven't customized the syntax of Xbase expressions, nor the
XbaseCompiler.
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | | | |
| Re: strange behavior for navigation to elements [message #1504553 is a reply to message #1503650] |
Tue, 09 December 2014 10:56  |
|
On 08/12/2014 18:04, Sebastian Zarnekow wrote:
> I would start at the HyperlinkHelper or one of its subtypes.
Hi Sebastian
here are some findings first for the navigation to Java types that don't
work in my DSL:
- I cannot reproduce that with Domainmodel example because:
public class DomainmodelHyperlinkHelper extends TypeAwareHyperlinkHelper {
so it does NOT extend XbaseHyperlinkHelper (the default for Xbase
languages).
XbaseHyperlinkHelper overrides
/**
* If multiple links are requested, all ambiguous candidates are
provided for feature and constructor calls.
*/
@Override
public IHyperlink[] createHyperlinksByOffset(XtextResource resource,
int offset, boolean createMultipleHyperlinks) {
if (!createMultipleHyperlinks) {
return super.createHyperlinksByOffset(resource, offset,
createMultipleHyperlinks);
}
List<IHyperlink> links = Lists.newArrayList();
IHyperlinkAcceptor acceptor = new HyperlinkAcceptor(links);
INode crossRefNode =
getEObjectAtOffsetHelper().getCrossReferenceNode(resource, new
TextRegion(offset, 0));
if (crossRefNode == null) {
this.createHyperlinksByOffset(resource, offset, acceptor);
} else {
this.createHyperlinksForCrossRef(resource, crossRefNode, acceptor);
}
if (!links.isEmpty())
return Iterables.toArray(links, IHyperlink.class);
return null;
}
since createMultipleHyperlinks is true it does not call the super
implementation, and when it gets to createHyperlinksForCrossRef it does:
protected void createHyperlinksForCrossRef(XtextResource resource,
INode crossRefNode,
final IHyperlinkAcceptor acceptor) {
EObject containedElementAt =
getEObjectAtOffsetHelper().resolveContainedElementAt(resource,
crossRefNode.getOffset());
if (containedElementAt instanceof XAbstractFeatureCall) {...
so it creates hyperlinks only for XAbstractFeatureCall skipping
completely Java type references...
is this intentional or is it a bug?
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: strange behavior for navigation to elements [message #1504573 is a reply to message #1504553] |
Tue, 09 December 2014 11:19 |
|
On 09/12/2014 11:56, Lorenzo Bettini wrote:
> On 08/12/2014 18:04, Sebastian Zarnekow wrote:
>> I would start at the HyperlinkHelper or one of its subtypes.
>
> Hi Sebastian
>
> here are some findings first for the navigation to Java types that don't
> work in my DSL:
>
> - I cannot reproduce that with Domainmodel example because:
>
> public class DomainmodelHyperlinkHelper extends TypeAwareHyperlinkHelper {
>
> so it does NOT extend XbaseHyperlinkHelper (the default for Xbase
> languages).
>
> XbaseHyperlinkHelper overrides
>
> /**
> * If multiple links are requested, all ambiguous candidates are
> provided for feature and constructor calls.
> */
> @Override
> public IHyperlink[] createHyperlinksByOffset(XtextResource resource,
> int offset, boolean createMultipleHyperlinks) {
> if (!createMultipleHyperlinks) {
> return super.createHyperlinksByOffset(resource, offset,
> createMultipleHyperlinks);
> }
> List<IHyperlink> links = Lists.newArrayList();
> IHyperlinkAcceptor acceptor = new HyperlinkAcceptor(links);
> INode crossRefNode =
> getEObjectAtOffsetHelper().getCrossReferenceNode(resource, new
> TextRegion(offset, 0));
> if (crossRefNode == null) {
> this.createHyperlinksByOffset(resource, offset, acceptor);
> } else {
> this.createHyperlinksForCrossRef(resource, crossRefNode, acceptor);
> }
> if (!links.isEmpty())
> return Iterables.toArray(links, IHyperlink.class);
> return null;
> }
>
> since createMultipleHyperlinks is true it does not call the super
> implementation, and when it gets to createHyperlinksForCrossRef it does:
>
> protected void createHyperlinksForCrossRef(XtextResource resource,
> INode crossRefNode,
> final IHyperlinkAcceptor acceptor) {
> EObject containedElementAt =
> getEObjectAtOffsetHelper().resolveContainedElementAt(resource,
> crossRefNode.getOffset());
> if (containedElementAt instanceof XAbstractFeatureCall) {...
>
> so it creates hyperlinks only for XAbstractFeatureCall skipping
> completely Java type references...
>
> is this intentional or is it a bug?
>
> cheers
> Lorenzo
>
>
So skipping XbaseHyperlinkHelper at all with this
@Override
public Class<? extends IHyperlinkHelper> bindIHyperlinkHelper() {
return TypeAwareHyperlinkHelper.class;
}
solves also all my other problems of the original message...
Can this be considered a bug of XbaseHyperlinkHelper?
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 13:29:58 GMT 2024
Powered by FUDForum. Page generated in 0.04132 seconds |
] 
Search
Help
Register
Login
Home
