Bug 334266

Comment 1 Mark Christiaens 2011-01-13 10:09:04 EST

Created attachment 186730 [details]
Screenshot of the current behaviour

Screenshot of the current behaviour

Comment 2 Sebastian Zarnekow 2011-01-13 10:16:31 EST

We tried to behave in the same way as the java editor does - try to invoke CA
e.g. for

public| boolean| foobar() {
  try| {
    return| true|;
  } finally| {
  }
}

where | indicates a cursor position.

Workaround: Override completeKeyword and filter as you like.
AbstractContentProposalProvider.createCompletionProposal(String, StyledString, Image, int, String, ContentAssistContext) can be used to insert a space after a keyword if you want.


We should discuss the behavior for keywords again, as this issue comes up from
time to time, but I'm inclined to keep the behavior as-is.

Comment 3 Mark Christiaens 2011-01-13 10:18:33 EST

I also noticed that the default auto-completion does the following.  In VHDL
you can close a process by typing "end process;" but it's also fine to type
"end;".  When I've typed "end pro" and request auto-completion, it presents me
with the options "process" and ";".  OK, that makes kind of sense I guess
(although I would prefer it to just complete the "process" I started to write).
 However, when I then select ";" the typed end result is "end pro;" which is
definitely not what I wanted.  Instead, I would then expect to get "end;".

Comment 4 Mark Christiaens 2011-01-13 10:21:27 EST

(In reply to comment #2)
> We tried to behave in the same way as the java editor does - try to invoke CA
> e.g. for
> 
> public| boolean| foobar() {
>   try| {
>     return| true|;
>   } finally| {
>   }
> }
> 
> where | indicates a cursor position.
> 
> Workaround: Override completeKeyword and filter as you like.
> AbstractContentProposalProvider.createCompletionProposal(String, StyledString,
> Image, int, String, ContentAssistContext) can be used to insert a space after a
> keyword if you want.
> 
> 
> We should discuss the behavior for keywords again, as this issue comes up from
> time to time, but I'm inclined to keep the behavior as-is.

I see, I just tried JDT again and for keywords it behaves a bit differently compared to identifiers.  For keywords it does present the "public" again.  For identifiers, it does not.

Comment 5 Sebastian Zarnekow 2011-01-13 10:30:12 EST

(In reply to comment #4)
> I see, I just tried JDT again and for keywords it behaves a bit differently
> compared to identifiers.  For keywords it does present the "public" again.  For
> identifiers, it does not.

String|.class

yields String, 

int foo, foo2 = 0;
int bar = foo|

shows foo, too but
StringBuilder|.class

does not show any proposals. Looks like they do not show the dialog if only one option is valid.

The issue with "end pro;" looks like the one that was fixed with
http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=a873b0f6b26476cc209fc69f9d8faf60a96d87e6

where the domain model 'entity X e|' brought up wrong proposals like '{'

Comment 6 Sven Efftinge 2012-11-19 08:53:25 EST

let's stick with the current default behavior as changing it might break existing client expectations and I don't like us to maintain two different strategies.