Eclipse Community Forums: TMF (Xtext) » Code completion following ambiguous operator

Help

Home

Home » Modeling » TMF (Xtext) » Code completion following ambiguous operator

Show: Today's Messages :: Show Polls :: Message Navigator

Code completion following ambiguous operator [message #1006242]

Wed, 30 January 2013 14:45

Ed Willink

Messages: 6852
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

Report message to a moderator

Re: Code completion following ambiguous operator [message #1006349 is a reply to message #1006242]

Wed, 30 January 2013 23:10

Sebastian Zarnekow

Messages: 3108
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

Report message to a moderator

Re: Code completion following ambiguous operator [message #1037090 is a reply to message #1006349]

Tue, 09 April 2013 06:54

Ed Willink

Messages: 6852
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

Report message to a moderator

Previous Topic:	Path expressions with dot and imports/packages
Next Topic:	Xtext-Ecore problem with cross-reference and abstraction/specialization

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Sep 28 22:31:08 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter