|Re: Code completion following ambiguous operator [message #1006349 is a reply to message #1006242]
||Wed, 30 January 2013 23:10
| Sebastian Zarnekow
Registered: July 2009
it should invoke
if the last complete node is a valid keyword but it is still undecided,
which one it represents, e.g. the dot could appear at different
locations in your grammar thus the grammar element 'keyword' is not yet
assigned. Looks like a bug to me if it does not invoke that method.
A possible fix is to invoke that method explicitly for such situations,
possibly guarded by isLikelyToBeValidProposal(..)
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 30.01.13 15:45, schrieb Ed Willink:
> In my (EssentialOCL) grammar both the following are valid. (A and B are
> arbitrary references to names. '.' and '..' are keywords.)
> If $ denotes the cursor position when requesting completion proposals
> 'A.$B' gives a very satisfactory completion assist response offering
> many possible B candidates
> 'A.$ ' gives a more limited response omitting B candidates
> In the past I recall an indication that Xtext's default code completion
> was deliberately limited where there might be too many options, so I
> deferred looking into what custom code I needed to provide. Now I'm
> It seems that Xtext has improved significantly and so I'm trying to make
> the responses for 'A.$ ' as good as for 'A.$B'.
> Stepping through the code it appears that the problem is that for the
> 'A.$ ' case, in ParserBasedContentAssistContextFactory.doCreateContexts,
> the 4th context which provides the desired results is skipped because
> lastCompleteNode.getGrammarElement() has not been assigned the Keyword
> for '.', whereas in the 'A.$B' case it has.
> Is this an outright bug?
> Should I try to assign the grammarElement manually to fix up assists?
> Is there another way to solve the problem?
> Ed Willink
Powered by FUDForum
. Page generated in 0.15654 seconds