Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313855

Summary:	Pressing right arrow key when Quick Assist pop-up is showing does not re-compute the proposals if the existing proposals are ICompletionProposalExtension2/ICompletionProposalExtension
Product:	[Eclipse Project] Platform	Reporter:	Sameer <prosameer>
Component:	Text	Assignee:	Platform-Text-Inbox <platform-text-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert
Version:	2.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Sameer

2010-05-21 02:26:14 EDT

Build Identifier: 20090920-1017

If I invoke Quick Assist and press the right arrow key, the proposals are re-computed only if the already existing proposals are not ICompletionProposalExtension2/ICompletionProposalExtension. Otherwise, they will be filtered by calling validate()/isValidFor() methods.
For example, consider that there is only one quick assist proposal showing and I press right arrow key. Now, this method will show more proposals by re-computing only if the existing proposal is not ICompletionProposalExtension2/ICompletionProposalExtension.
In case of left arrow key, the proposals are re-computed everytime without validating the existing proposals.
So basically, the implementation of 
org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeFilteredProposals() method is wrong.

Reproducible: Always

Steps to Reproduce:
1. Implement Quick Assist for any editor.
2. Create a proposal implementing ICompletionProposalExtension2 and provide it for Quick Assist.
3. Now, invoke Quick Assist by pressing Ctrl+1.
4. Press the right arrow.
Result: Nothing will be shown
Expected: The proposals should be re-computed and shown.
Note: It works when the left arrow key is pressed.

Comment 1 Dani Megert

2010-05-21 04:41:19 EDT

The two interfaces are exactly for the filtering purpose. If you don't want the proposals to support that then don't implement those interfaces or make sure that validate always returns true.

Comment 2 Sameer

2010-05-21 04:50:24 EDT

I can make the validate return true. But that does not solve the issue.
Consider this case: I invoke Quick Assist and one proposal is shown. Now, I press the right arrow key. If I return true from the validate() method, then also I'll not get the new proposals valid for the new offset. The method is just filtering the existing proposals and not checking if there are any proposals which are valid for the new offset.
This behavior is only present in case when the offset increases (by pressing the  right arrow key). For left arrow key press (offset decreases), the proposals are just re-computed every time!

(In reply to comment #1)
> The two interfaces are exactly for the filtering purpose. If you don't want the
> proposals to support that then don't implement those interfaces or make sure
> that validate always returns true.

Comment 3 Dani Megert

2010-05-21 04:54:53 EDT

I see your point but again, this is as designed to allow filtering and we won't change that. If returning 'true' does not work then simply don't extend those interfaces.

Comment 4 Sameer

2010-05-21 06:18:31 EDT

Then atleast this behavior can be made consistent for left key and right key.
Right now, there is no filtering in case of left key.

(In reply to comment #3)
> I see your point but again, this is as designed to allow filtering and we won't
> change that. If returning 'true' does not work then simply don't extend those
> interfaces.

Comment 5 Dani Megert

2010-05-21 06:52:12 EDT

It's by design that we only filter when going from left to right. Please don't reopen this again.

Comment 6 Sameer

2010-05-21 07:15:00 EDT

Atleast, can you give reasons behind this design approach because I don't see it solving the purpose of filtering....

Comment 7 Dani Megert

2010-05-21 08:33:25 EDT

The reason is that we want filtering by going to the right and get more results when going to the left. Now, it's obvious that if you move left past the initial invocation you need to recompute the proposals, since there can be more. We could have optimized the code to cache the initial result and use that (undo filtering) until the caret moves past the initial invocation but that seemed to be overkill.