| Code completion following ambiguous operator [message #1006242] |
Wed, 30 January 2013 09:45  |
Eclipse User |
|
|
|
Hi
In my (EssentialOCL) grammar both the following are valid. (A and B are
arbitrary references to names. '.' and '..' are keywords.)
'A.B'
'A..B'
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 looking.
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?
Regards
Ed Willink
|
|
|
| Re: Code completion following ambiguous operator [message #1006349 is a reply to message #1006242] |
Wed, 30 January 2013 18:10  |
| Eclipse User |
|
|
|
Hi Ed,
it should invoke
ParserBasedContentAssistContextFactory.StatefulFactory.handleLastCompleteNodeHasNoGrammarElement(List<Builder>,
EObject)
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(..)
Regards,
Sebastian
--
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:
> Hi
>
> In my (EssentialOCL) grammar both the following are valid. (A and B are
> arbitrary references to names. '.' and '..' are keywords.)
>
> 'A.B'
> 'A..B'
>
> 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
> looking.
>
> 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?
>
> Regards
>
> Ed Willink
|
|
|
| Re: Code completion following ambiguous operator [message #1037090 is a reply to message #1006349] |
Tue, 09 April 2013 02:54 |
| Eclipse User |
|
|
|
Hi Sebastian
It does as you say.
For the record the problem was caused by skipping semantic analysis in
the presence of syntactic errors, since the knock-on semantic errors
swamp the syntactic errors that the user needs to cure. Without the
semantic analysis the type information for the navigation source was
null and no completion proposals were provided. Simple solution was to
perform the skipped semantic analysis at the start of the completion
proposal computation.
Regards
Ed Willink
On 30/01/2013 23:10, Sebastian Zarnekow wrote:
> Hi Ed,
>
> it should invoke
>
> ParserBasedContentAssistContextFactory.StatefulFactory.handleLastCompleteNodeHasNoGrammarElement(List<Builder>,
> EObject)
>
> 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(..)
>
> Regards,
> Sebastian
|
|
|
Powered by
FUDForum. Page generated in 0.06089 seconds
Home