Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Code completion following ambiguous operator
Code completion following ambiguous operator [message #1006242] Wed, 30 January 2013 14:45 Go to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
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 23:10 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 2961
Registered: July 2009
Senior Member
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 06:54 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
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
Previous Topic:Path expressions with dot and imports/packages
Next Topic:Xtext-Ecore problem with cross-reference and abstraction/specialization
Goto Forum:
  


Current Time: Sun Dec 21 18:06:50 GMT 2014

Powered by FUDForum. Page generated in 0.02874 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software