How can we make the completion engine more responsive and also interruptible if the user types fast?

The underlying database needs some love, I think that operations are doing redundant work.

Updating tickets (#831, #930, #807, #847, #859, #608, #909, #914, #916, #917, #919)

Updating tickets (#861, #908, #916, #917, #831, #608, #834, #870, #889, #894, #919, #876, #847, #858, #859, #882, #930, #891, #909, #933, #934, #932, #807)

The completion processor is called in the main thread, so it blocks the UI until it returns. With all sgsn projects open in the workspace, the first invocation of the completion processor takes *20 seconds*! After that, at each keypress (while completing) it takes ~400ms, which is still too much. Typing fast queues requests for each character, and completion is called needlessly each time.

JDT uses an asynchronous model, where the completion popup is shown right away and the results are shown as they are computed. This would help for the initial computation.

We should also detect if user types fast and cancel ongoing computations.

This kind of problems are solved in DLTK/Xtext - so one additional question is how much time we spend on trying to fix it ourselves, or copying and adapting code from JDT/DLTK , if we are planning to use these existing frameworks anyway...

Within the scope of this sprint, I think we should change to an asynchronous completion processor. It should be 2 or 3 days of work, shouldn't it? I'll be happy to do it if you don't have time for it.

The tricky part are the corner cases and I would rather use some code that is already tested for these (like from JDT or DLTK), but from experience we know it's not very easy to pick parts of JDT, because we have some different background (for example, no working copy concept).

I will see what I can do about that, but I hate having to work for nothing (if we will end using some framework anyway).

"it's not very easy" == it takes longer than we think from the start :-)

We're talking of about 50 classes and plenty of extension points and other fun stuff...........

And everything is also tightly connected to the model (for example it is Openable that has a "codeComplete" method that does the work)

Updating tickets (#917, #831, #972, #983, #978, #957, #964, #834, #935, #943, #955, #956, #916)

Updating tickets (#916)

Updating tickets (#64, #858, #882, #916, #930, #1003, #1004, #937, #965, #966, #967, #968, #1002)

Updating tickets (#156, #747, #805, #806, #972, #194, #274, #335, #339, #375, #603, #610, #641, #642, #664, #665, #684, #743, #744, #759, #760, #762, #796, #800, #809, #820, #853, #856, #857, #884, #893, #900, #902, #916, #917, #953, #969, #990, #1002, #1003, #1004, #1011, #1012, #1044, #40, #119, #121, #129, #130, #145, #160, #244, #264, #265, #387, #392, #433, #454, #459, #463, #479, #508, #524, #529, #536, #589)