Improving CamelHumps classname completion: ideas and suggestions


I've been using CamelHumps in the Ctrl-N and Ctrl-Alt-N popups for as long
as I can remember.
After using the new CamelHumps classname completion for a few minutes, I'm
completely hooked.

After using this on a few bigger projects (compiling on JDK 1.5, having 30-40
library dependencies), the plethora of classes on the classpath seems to
diminish the value. The simple fact is that, for any given CamelHumps pattern,
there are at least a couple of matches somewhere in the classpath.

There are a number of reasons for this:
1) Lack of anything between 'package private' and 'public' for class visibility
in Java. A great number of classes in my classpath are public, but should
propably be 'jar/library private'. Not much to be done about this.

2) No ability to exclude JDK implementation classes from classname completion.
Using sun.* classes is bad form, while sometimes there is no other way. However,
excluding JDK implementation classes from classname completion would significantly
reduce the 'CamelHumps classname namespace' pollution. It should be trivial
to implement too, simply filtering on package name pattern. It should be
configurable, and defaulting the the current behaviour off course.

3) No ability to differentiate project libraries in 'primary dependencies'
and 'second-level' or transitive dependencies.

For instance, I have direct dependencies on spring, hibernate and antlr.
Some of these libraries depend on various Jakarta Commons libraries (commons-collections
etc).

I wouln't touch any jakarta-commons code with a 10-foot pole. However, some
of my primary dependencies depend on it, so the classnames of the contained
classes are presented in classname completion lists.

Having a per-library setting "Exclude from classname completion" would greatly
improve CamelHumps accuracy.


2 comments
Comment actions Permalink


These are all good ideas, and well explained. Various solutions to all of your points have been proposed, and a search of the Tracker or Jira archives would show multiple requests for each of the functionalities described.

In short, yup, you're right, but don't hold your breath.

--Dave Griffith

0
Comment actions Permalink

The best match I found was:

"Filter certain packages from the alt-enter import mechanism. (eg sun.*)"
http://www.jetbrains.net/jira/browse/IDEA-1524

It would be trivial to generate properly configured module files (having
this distinction in library type) from newer project management systems descriptors
like Ivy or the new Maven version. All the information (runtime library yes/no)
is already there.

On a related note, an idea for a faster CamelHumps:
"Treat all-lowercase CamelHumps completion pattern as all-uppercase"
http://www.jetbrains.net/jira/browse/IDEA-2452

These are all good ideas, and well explained. Various solutions to
all of your points have been proposed, and a search of the Tracker or
Jira archives would show multiple requests for each of the
functionalities described.

In short, yup, you're right, but don't hold your breath.

--Dave Griffith



0

Please sign in to leave a comment.