Content assist slow and erratic
User reports that content assist in ErlIDE can be excessively slow. Also it can insert reckless things in the code on an incomprehensible way. I wasn't able to reproduce the behavior.
The only problem I've noticed with content assist is that rarely it doesn't work after I type 3 or 4 characters, but starts working when I delete the preceding character with backspace.
The only problem I've noticed with content assist is that rarely it doesn't work after I type 3 or 4 characters, but starts working when I delete the preceding character with backspace.
Leave a comment
on 2011-09-22 19:28 *
By Vlad Dumitrescu
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.
The underlying database needs some love, I think that operations are doing redundant work.
on 2011-09-27 19:26 *
By Vlad Dumitrescu
Component changed from None to editing support
Component changed from None to editing support
on 2011-10-14 19:47 *
By Vlad Dumitrescu
Assigned to set to Vlad Dumitrescu
Status changed from New to Ongoing
Assigned to set to Vlad Dumitrescu
Status changed from New to Ongoing
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...
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...
on 2011-10-14 20:32 *
By Vlad Dumitrescu
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).
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).
on 2011-10-14 20:33 *
By Vlad Dumitrescu
"it's not very easy" == it takes longer than we think from the start :-)
on 2011-10-14 20:58 *
By Vlad Dumitrescu
We're talking of about 50 classes and plenty of extension points and other fun stuff...........
on 2011-10-14 21:45 *
By Vlad Dumitrescu
And everything is also tightly connected to the model (for example it is Openable that has a "codeComplete" method that does the work)
on 2011-11-14 21:25 *
By Vlad Dumitrescu
Milestone changed from sprint #25 - 0.13.7 to sprint #26
Milestone changed from sprint #25 - 0.13.7 to sprint #26
on 2011-12-12 23:21 *
By Vlad Dumitrescu
Milestone changed from sprint #26 - 0.13.9 to sprint #27
Milestone changed from sprint #26 - 0.13.9 to sprint #27
on 2012-01-12 22:18 *
By Vlad Dumitrescu
Assigned to changed from Vlad Dumitrescu to -none-
Assigned to changed from Vlad Dumitrescu to -none-
on 2012-01-30 17:41 *
By Vlad Dumitrescu
Milestone changed from sprint #28 - 0.15 to sprint #29 - 0.16
Milestone changed from sprint #28 - 0.15 to sprint #29 - 0.16
Updating tickets (#916)
on 2012-02-14 15:18 *
By Vlad Dumitrescu
Status changed from Ongoing to New
Status changed from Ongoing to New
on 2012-06-01 20:22 *
By Vlad Dumitrescu
Milestone changed from backlog to deprecated because of xtext version
Milestone changed from backlog to deprecated because of xtext version
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)
on 2013-01-09 18:21 *
By Vlad Dumitrescu
Affected by xtext set to Yes
Milestone changed from deprecated because of xtext version to backlog
Affected by xtext set to Yes
Milestone changed from deprecated because of xtext version to backlog
on 2013-01-09 18:27 *
By Vlad Dumitrescu
Priority changed from Normal (3) to High (2)
Priority changed from Normal (3) to High (2)
on 2013-01-24 20:47 *
By Vlad Dumitrescu
Found in version changed from 0.13 to -none-
Erlang engine changed from No to Yes
Found in version changed from 0.13 to -none-
Erlang engine changed from No to Yes
on 2013-07-03 01:43 *
By Vlad Dumitrescu
Milestone changed from backlog to v1.0
Milestone changed from backlog to v1.0