Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313855 - Pressing right arrow key when Quick Assist pop-up is showing does not re-compute the proposals if the existing proposals are ICompletionProposalExtension2/ICompletionProposalExtension
Summary: Pressing right arrow key when Quick Assist pop-up is showing does not re-comp...
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-21 02:26 EDT by Sameer CLA
Modified: 2010-05-21 08:33 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sameer CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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.