Community
Participate
Working Groups
(| denotes cursor position) grammar org.xtext.example.mydsl1.MyDsl with org.eclipse.xtext.common.Terminals generate myDsl "http://www.xtext.org/example/mydsl1/MyDsl" Model: greetings+=Greeting*; Greeting: ('Hello' name=ID '!'| Hit enter and be surprised: Greeting: ('Hello' name=ID '!' )| ); ======================= Second example for unwanted auto edit: Greeting: |'Hello' name=ID '!'; Type '(' and you'll get Greeting: (|)'Hello' name=ID '!'; where the Java editor only adds the opening brace which works better imo.
maybe we should simplify the second issue such that it never adds the closing bracket if there's a non WS-char right to the cursor and make it the default for all languages.
Not 2.1
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.xbase.Xbase generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" Model: 'package' name=QualifiedName '{'| ; Hit enter at cursor position and you'll get grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.xbase.Xbase generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" DomainModel: 'package' name=QualifiedName '{' | } ; which is _really_ annoying. Set severity to major and scheduled for M6.
(In reply to comment #1) > maybe we should simplify the second issue such that it never adds the closing > bracket if there's a non WS-char right to the cursor and make it the default > for all languages. I have tried that and it feels strange, especially adding an opening parenthesis before a ';' or a closing parenthesis. The current rule is not to insert the closing temrinal when the following character can be part of a Java identifier. I'd rather add quotes here, too.
(In reply to comment #4) > The current rule is not to insert the closing temrinal when the following > character can be part of a Java identifier. I'd rather add quotes here, too. +1 I think quotes and numbers should be added there.
(In reply to comment #5) > (In reply to comment #4) > > > The current rule is not to insert the closing temrinal when the following > > character can be part of a Java identifier. I'd rather add quotes here, too. > > +1 > I think quotes and numbers should be added there. I am going for Character.isJavaIdentifierPart(charAtOffset) || charAtOffset == '\'' || charAtOffset == '\"'
> (In reply to comment #1) > > maybe we should simplify the second issue such that it never adds the closing > > bracket if there's a non WS-char right to the cursor and make it the default > > for all languages. > > I have tried that and it feels strange, especially adding an opening > parenthesis before a ';' or a closing parenthesis. Would you expect a closing bracket when there's already one right to the cursor? (In reply to comment #5) > (In reply to comment #4) > > > The current rule is not to insert the closing temrinal when the following > > character can be part of a Java identifier. I'd rather add quotes here, too. > > +1 > I think quotes and numbers should be added there. What about operators?
(In reply to comment #3) > grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.xbase.Xbase > > generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" > > Model: > 'package' name=QualifiedName '{'| > ; > > Hit enter at cursor position and you'll get > > grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.xbase.Xbase > > generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" > > DomainModel: > 'package' name=QualifiedName '{' > | > } > ; > > which is _really_ annoying. Set severity to major and scheduled for M6. Deeper testing reveals that this is likely due to broken partitioning data in the document. The bug does not show if you just paste the example in a new document, but it happens when you delete the inserted newline and hit enter again. I've opened bug 373081 to solve this.
(In reply to comment #7) > > (In reply to comment #1) > > > maybe we should simplify the second issue such that it never adds the closing > > > bracket if there's a non WS-char right to the cursor and make it the default > > > for all languages. > > > > I have tried that and it feels strange, especially adding an opening > > parenthesis before a ';' or a closing parenthesis. > > Would you expect a closing bracket when there's already one right to the > cursor? Yes. > (In reply to comment #5) > > (In reply to comment #4) > > > > > The current rule is not to insert the closing temrinal when the following > > > character can be part of a Java identifier. I'd rather add quotes here, too. > > > > +1 > > I think quotes and numbers should be added there. > > What about operators? Not sure. My impression is that if the following char could be something like an argument to a function call, no closing terminal should be added. This would only hold for prefix operators.
Yes, I think that's something language specific. We should do that for Xbase with the same heuristics as Java does.
(In reply to comment #10) > Yes, I think that's something language specific. We should do that for Xbase > with the same heuristics as Java does. Not sure what exactly you're referring to :-) Could you file a separate ticket for Xbase? I've changed the deafult behavior as stated in comment #6. It's a good sign I only had to adapt a single test our extensive autoedit test suite, that exactly refers to inserting a '(' before a quote. I've pushed my changes to MASTER, so I assume that this particular ticket is resolved.
(In reply to comment #9) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > > > > The current rule is not to insert the closing temrinal when the following > > > > character can be part of a Java identifier. I'd rather add quotes here, too. > > > > > > +1 > > > I think quotes and numbers should be added there. > > > > What about operators? > > Not sure. My impression is that if the following char could be something like > an argument to a function call, no closing terminal should be added. This would > only hold for prefix operators. I agree and think that's the point. A closing parenthesis should never be added if the following character can be the start of an 'expression'. In addition to the mentioned java identifier start, numbers, quotes (i.e. string literals) it should also include prefix operators as well as opening parenthesis. So I added '-', '!', '(', '{','[' to the list. Of course we are assuming some kind of expression language here which might look very different from case to case (i.e. Xtext grammar expressions are very different to Xbase), but I think it's a good match and it's better to not insert anything automatically when in doubt. Let's se how it "feels".
Closing all bugs that were set to RESOLVED before Neon.0
