Codetrails continuously strives to improve your performance by building tools that let you develop code faster with Eclipse. If you know Eclipse Code Recommenders then you probably know that (among other things) we spent quite some time on improving Eclipse’s content assist.
In case you wonder why, the answer is pretty simple: We improve content assist because it is the fifth-most frequently used command in the IDE. Right after
Save, (Jump to)
Next Word and Paste:
If you put aside basic commands like
Delete (a character), it’s even the most frequently used non-trivial command in your IDE. If that isn’t a big enough incentive to improve things, I don’t know what is.
A little bit of history
In the past we tested many different ranking systems to let Eclipse content assist learn which proposals are actually relevant for a developer’s task at hand and allowed it to put the important ones on top of the content assist list. The results are quite good (though they still could be improved as latest research shows):
However, given that we received more than half a million JRE model download requests in the past 4 months shows that Code Recommenders has become a popular project that piques a lot of interest among developers.
But predicting what a developer needs next, is only one of the things we worked on. Back in 2011 we followed another approach to content assist and developed Subwords completion; a completion engine which lets you type arbitrary subwords of a completion proposals’ text instead of specifying it from the very beginning as prefix match. As of today every major IDE includeds similar subwords completion techniques (and I’ve to admit, in some of them they work even better than in Eclipse).
Allow me a short detour:
To analyze shortcomings of Eclipse content assist, a we asked our users to share their completion statistics with us a few months ago. In the meanwhile more than 400 users shared over 270.000 code completion events and gave us some interesting insights in how well code completion works. Thank you for sharing!
There is one finding I don’t want to withhold: The pictures below summarize the common code completion prefixes developers typed in the beginning of our study (left) and the completion tokens they type today (right). As you see, the length of the completion prefixes has changed a lot since then. In the beginning, people actually used longer prefixes (like set, get etc.), today they frequently use single letters (or even empty prefixes) much more often then before to pick their proposal. To me this was fun to see, as it shows that Code Recommenders, Codetrails Connect, and Subwords completion do a quite good job in putting the right things on top without a lot of user input:
I could elaborate much more on this. But today I originally just wanted to announce new releases of Eclipse Code Recommenders and Codetrails Connect which fix some long standing issues with Subwords completion and type completion in Eclipse.
You can get the latest versions of both, Codetrails Connect and Code Recommenders, from the Eclipse Marketplace (client or web) or - if already installed - simply by running the Eclipse Update wizard.
News from Codetrails Connect Completion Tweaks – Rethinking How JDT Ranks Type Proposals
Codetrails Connect, which is our crowdsourcing-based content assist engine for Eclipse, was released in version 1.2.11. One of the major improvements made in this release are our latest additions and performance improvements to the Completion Tweaks plugin.
The completion tweaks plugin is an add-on to Eclipse Code Recommenders and focuses on putting type and constructor proposals at the right position, for instance, when triggered on an assignment to
java.util.List, the Completion Tweaks plugin puts subtypes of
List on top of the list:
The very same works for constructor invocation on method arguments:
These features have been around for some time, but I thought it would make sense to repeat them here. What has changed in v1.2.11 is its performance. We significantly improved the performance of the subtypes checks by caching intermediate results, and thus, should make subtypes completions a must-have in every developer’s IDE.
Note that neither method return types nor local variables are yet considered. But we may add support for this soon.
Another feature we added to this release is the „Imported Types“ boost.
You probably know the following situation quite well: Whenever you type „
Date“ and trigger content assist, it will most likely propose
java.util.Date just because
sql comes before
Other incarnations of this problem are
java.awt.List vs. java.util.List or
org.eclipse.swt.widgets.Button. The reason why Eclipse fails here is, that it does not consider which packages and types have been imported already. By boosting types that stem from already imported packages, we can fix this issue in most cases:
We added this new feature to the Completion Tweaks plugin and it’s waiting for your tests. Let us know whether you find it useful in its current version during your daily work. The Completion Tweaks plugin is a part of Codetrails Connect and can be installed from the Marketplace.
Improving Subwords Completion in Code Recommenders
We also released Eclipse Code Recommenders in version 2.1.8, where we focused our efforts on the Subwords completion. We implemented a user request to have subwords proposal appear below Eclipse’s template proposals. Previously, hard-learned prefixes like
syso didn’t work well with Subwords enabled. I’m happy to say, this issue is history now:
Subwords now also respects exact camel case matching, and thus, is much closer to the expectations of our users:
In addition, we fixed Subwords boosting fields and types in Javadocs too much, and fixed a couple more minor issues you might (or might not) have noticed during your daily work.
Heads Up: New Limitation in Subwords
Unfortunately, we also had to limit Subwords for type and constructor completions: In previous versions, you could use Subwords for type and constructor completions in nearly the same way as when invoking it on (member) methods and fields. Due to the way how JDT’s code completion works you had to specify the first letter of the type name you were looking for. For example, to match
ArrayList, you just had to type
As of version 2.1.8, we now require you to specify at least two prefix letters for type and constructor completions due to performance reasons in JDT:
I hope you’ll not notice this limitation too often. But putting this limitation into Subwords was necessary since JDT requires 10-20x more time when finding types and constructors with one prefix letter compared to triggering content assist with two prefix letters. This quickly sums up into a second or two where a user waits for content assist which wasn’t acceptable for large workspaces.
However, if your workspaces are small enough, you can get back the old behavior by setting the minimum prefix length back to „1“ in Subwords preferences:
Have fun and let us know what you think about these changes. In case you want to disable some of the content assistants, simple disable them in the Completions preference page: