Bug 539199 - All proposal filtered should trigger a new completion request
Summary: All proposal filtered should trigger a new completion request
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.8   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 4.10 M1   Edit
Assignee: Mickael Istria CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-18 15:18 EDT by Mickael Istria CLA
Modified: 2018-09-22 14:20 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 Mickael Istria CLA 2018-09-18 15:18:36 EDT 
Assuming I have an editor with can complete Fo to Foo and Foo. to Foo.Bar ; Auto-activation is enabled; the . character is NOT marked as completion proposal trigger char, or the trigger proposal trigger chars are disabled ( bug 539165 ).
If I start a completion session after Fo, then Foo is proposed, ok. Then if I press enter, then the proposal is inserted, completion session is stopped, so if I type . after that, it starts a new session and Bar is proposed, ok.
Now, if I start a completion session after Fo, then Foo is proposed, ok. Then if I keep typing o, the completion session remain and Foo is still proposed. ok. Then if I type . then all elements are filtered out, completion session is stopped and I don't get proposals for Bar. Not OK.

I would expect that when all proposals are filtered out, a new completion session would start to request content assist processors for fresher content according to the last change.
Comment 1 Eclipse Genie CLA 2018-09-18 15:54:26 EDT 
New Gerrit change created: https://git.eclipse.org/r/129658
Comment 3 Mickael Istria CLA 2018-09-21 04:05:07 EDT 
Done.
Comment 4 Andrey Loskutov CLA 2018-09-22 10:55:42 EDT 
(In reply to Mickael Istria from comment #3)
> Done.

Mickael, I haven't looked deeper yet, but I fear that this change broke few JDT  UI tests, and may be not just tests.

http://download.eclipse.org/eclipse/downloads/drops4/I20180922-0245/testresults/html/org.eclipse.jdt.ui.tests_ep410I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html 

There are LOT of them, just one here for example:

testSurroundWithRunnable19

Wrong number of proposals, is: 0, expected: 1 

junit.framework.AssertionFailedError: Wrong number of proposals, is: 0, expected: 1

at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.TestCase.assertTrue(TestCase.java:192)
at org.eclipse.jdt.ui.tests.quickfix.QuickFixTest.assertNumberOfProposals(QuickFixTest.java:528)
at org.eclipse.jdt.ui.tests.quickfix.SurroundWithTemplateTest.testSurroundWithRunnable19(SurroundWithTemplateTest.java:933)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
Comment 5 Andrey Loskutov CLA 2018-09-22 14:20:55 EDT 
(In reply to Andrey Loskutov from comment #4)
> (In reply to Mickael Istria from comment #3)
> > Done.
> 
> Mickael, I haven't looked deeper yet, but I fear that this change broke few
> JDT  UI tests, and may be not just tests.

I've looked now deeper, this change is not guilty, it was bug 535964 http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=bb4abd131785dc66b2a4da321ded042fd4e37db1