code assist has isssues

[mchlrch]

I noticed a couple of issues with code assist ATM.

Invoking code-assist in empty .xrm file leads to keywords proposed that shouldn't be shown, for example the attributes of CSV dialect, like commentPrefix:

Invoking code-assist in the PredicateObjectMapping, after the property shows properties as proposals:

[nnamtug]

Separating problems. For the first screenshot, where all keywords from DialectGroup are offered on an empty file:

Before, the grammar for the DialectGroup looked like:

DialectGroup:
    'dialect' name=ID BLOCK_BEGIN
        'delimiter' delimiter=STRING &
        // ...
        ('trim' trim=BooleanLiteral)? &
    BLOCK_END;

So you have to use the keyword 'dialect', assign a name, use brackets and then you can define a bunch of optional properties (where 'delimiter' is mandatory). Using the ampersands '&' means you can define properties of a DialectGroup in an arbitrary order (XText calls this an "Unordered Group"). This is handy but messes with code completion. XText has to build proposals for keywords without having the model instance at hand. This is done in FollowElementComputer, which performs a lookahead in your grammr. When using UnorderedGroups, all keywords will be provided in the contentassist (bug? not sure - don't think so). Code completion would work as expected when I removed the "&" and use an ordinary, ordered group.

Solution: Split rule 'DialectGroup' into 'DialectGroupDescription'

Why this solves the problem: When calculating the lookahead described above, the FollowElementComputer will not follow containments. The new grammar therefore looks like:

DialectGroup:
    'dialect' name=ID BLOCK_BEGIN
        content=DialectGroupContent
    BLOCK_END;

DialectGroupContent:
    'delimiter' delimiter=STRING &
    // ...
    ('trim' trim=BooleanLiteral)? // <-- no ampersand here
    ;

No migration of existing models is required.

[nnamtug]

For the second screenshot:

map EmployeeMapping from EMPLOYEE {
    subject template "http://airport.example.com/{0}" with id;

    types
        employee:Employee

    properties    
        employee:no (1) from EMPNO;

When going for code completion at the spot marked with (1), the cursor is at the position of the potential second assignment (term) of PredicateObjectMapping:

PredicateObjectMapping: 
    property=[RdfProperty|RdfPrefixedName] 
    term=ValuedTerm?
;

The assignment term=ValuedTerm has to be optional, in order to get the Quickfix 'missingRdfProperty' working see RdfMapping.xtext:128. But since this assignment is optional, it would be OK to reference another property at this location. On what locations can we launch the code completion then:

properties
  (1)
  employee:no (2) from EMPNO;
  (3)
  thing:color parent-map EmployeeMapping2;
  (4)

• Spot 1, 3, 4: proposal 'thing:size' is fine - it would create a new PredicateObjectMapping
• Spot 2: proposal 'thing:size' is grammar-wise fine too, it would lead the reference to employee:no orphanized and the new statement would be 'thing:size from EMPNO;', which is rubbish. But it is possible to decide whether the cursor is in a PredicateObjectMapping or in a ValuedTerm. So this leads to the Solution: Do not offer cross references when the previousModelObject is a PredicateObjectMapping.