search

anuragraghavan / franca

Automatically exported from code.google.com/p/franca
0 stars 0 forks source link

Content assist doesn't offer keyword "method" in Franca IDL editor. #49

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Create an interface with only one attribute. Activate Content Assist after the 
attribute definition. "method" will not be offered.

Original issue reported on code.google.com by klaus.birken@gmail.com on 21 Jun 2013 at 7:50

GoogleCodeExporter commented 9 years ago 
Here is an example which can be copied into an existing fidl-file.

interface ContentAssistBug {
     /* Content Assist here:
      *    <** 
      *    version
      *    attribute
      * 
      * Missing:
      *    method
      *    broadcast
      *    (maybe some more)
      */    
}

interface ContentAssistBug2 {
    attribute UInt8 x noSubscriptions

    /* Content Assist here:
     *    <**
     *    array
     *    attribute
     *    broadcast
     *    (and many more)
     * 
     * Missing:
     *    method
     */
}

This might be a problem in the underlying framework (Xtext), but it is to be 
analysed first. If its an Xtext problem, we might need a smaller example.

Original comment by klaus.birken@gmail.com on 5 Jul 2013 at 11:11

GoogleCodeExporter commented 9 years ago 
I confirm: same symptoms in my IDE.

Original comment by bonge...@gmail.com on 11 Jul 2013 at 9:50

GoogleCodeExporter commented 9 years ago 
I reproduced the prob in a small grammar (see attached MyDsl.xtext) and filed 
an Xtext-support issue (german):

Hallo Support,

in einem neuen Xtext-Projekt mit angehängter Grammatik (keine Angst, ist klein 
und stellt lediglich das Prob nach) bekomme ich bei CodeCompletion weniger 
Proposals als erwartet.
Die Symptome sind im diesem Modell kommentiert:
{                
        // proposals hier sind: <**, attribute
        // es fehlt: method, broadcast, }
        attribute a
        // proposals hier sind: <**, attribute, noSubscriptions
        // es fehlt: method, broadcast, }
        attribute b noSubscriptions
        // proposals hier sind: <**, attribute, broadcast, }
        // es fehlt: method
}        

Beim Debuggen bin ich bis
org.xtext.example.mydsl.ui.contentassist.antlr.MyDslParser.getFollowElements(Abs
tractInternalContentAssistParser)
gekommen, mir scheint der InternalMyDslParser liefert zu wenig followElements.

Wenn ich in der Grammatik am FModel die äußeren geschweiften Klammern 
weglasse, läuft alles wie erwartet.
Geht das auch, ohne das ich an der Grammatik etwas ändere?

Original comment by bonge...@gmail.com on 11 Jul 2013 at 1:36

GoogleCodeExporter commented 9 years ago

Original comment by bonge...@gmail.com on 11 Jul 2013 at 1:37

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This might be a problem not in the underlying framework (Xtext), but in the 
underlying framework of the underlying framework (antlr).  

There are two possible workarounds, both affecting the grammar:
(1) Create an abstraction of FModel-artifacts, i.e. something like
{FModel} '{' elements+=AbstractElement* '}' ;
AbstractElement: FAttribute|FMethod|FBroadcast ... ; 

(2) Do not insist of the order of FModel-artifacts, i.e. something like
(attributes+=FAttribute | methods+=FMethod | broadcasts+=FBroadcast ... )* 

To me, alternative (1) seems cleaner, but implies a refactoring the underlying 
metamodel. Is that acceptable?

Both workarounds affect the order of FModel-artifacts, e.g. it would be 
possible to mix FAttributes and FMethods. We could prevent this by additional 
validations and some adjustedments to the ProposalProvider if the order has to 
be strict.

Please comment.

Original comment by bonge...@gmail.com on 12 Jul 2013 at 7:59

GoogleCodeExporter commented 9 years ago

Original comment by bonge...@gmail.com on 12 Jul 2013 at 7:59

GoogleCodeExporter commented 9 years ago 
The order of FModel artifacts is currently fixed by design, this is a 
requirement. Thus, additional validations and ProposalProvider-adjustments will 
be needed. 

Solution (1) would indeed require to adapt all downstream generators and 
transformations... this should be avoided at the moment. Maybe we can do this 
when putting Franca to eclipse.org later this year, then an API change could be 
acceptable (because there will be changes anyway).

Hence: Solution (2) is the preferred one at the moment. With additional changes 
to preserve the ordering behavior.

Original comment by klaus.birken@gmail.com on 12 Jul 2013 at 8:17

GoogleCodeExporter commented 9 years ago 
Postponed to next release.

Original comment by klaus.birken@gmail.com on 27 Aug 2013 at 12:42

GoogleCodeExporter commented 9 years ago 
Postponed - it is not clear at the moment if the proposed workaround is 
necessary or if Xtext provides some fixes to the content assist algorithm. The 
latter would be the preferred solution, we want to avoid changing the IDL 
semantics just for the sake of fixing content assist.

Original comment by klaus.birken@gmail.com on 26 Sep 2013 at 2:33