Restrict autocomplete, autoimport, etc?

Is there a way to restrict the list of offered classes in auto-*
popups? E.g. I want only to get automatically offered classes
from certain packages.
I'm don't recall anything like that in IDEA but I may be wrong.

AFAIK, Eclipse has this feature and it seems to be quite useful.
Especially in larger projects or projects depending on many
libraries (org., weblogic., javax.* - most of these are not
needed for regular business logic coding).

r.

6 comments

Hellow. Suppose your project library set should not include jars with packages you are not allowed to use. No?

0

You can filter completions/imports by setting up module structure in your
project.
Eugene.

"Richard Nemec" <rndzank@attbi.com> wrote in message
news:ckj4sd$ghc$1@is.intellij.net...

Is there a way to restrict the list of offered classes in auto-*
popups? E.g. I want only to get automatically offered classes
from certain packages.
I'm don't recall anything like that in IDEA but I may be wrong.

>

AFAIK, Eclipse has this feature and it seems to be quite useful.
Especially in larger projects or projects depending on many
libraries (org., weblogic., javax.* - most of these are not
needed for regular business logic coding).

>

r.



0

1. That's too inflexible and almost always impossible.
2. The "offer-restricted packages/classes" may be used in the
code (same class or other classes in the same package).
It's just inconvenient to see classes - that a particular
developer never uses - to be included in the popups.
(this may also answer Patrik's question)

Evgueny Vigdorchik wrote:

You can filter completions/imports by setting up module structure in your
project.
Eugene.

"Richard Nemec" <rndzank@attbi.com> wrote in message
news:ckj4sd$ghc$1@is.intellij.net...

>>Is there a way to restrict the list of offered classes in auto-*
>>popups? E.g. I want only to get automatically offered classes
>>from certain packages.
>>I'm don't recall anything like that in IDEA but I may be wrong.
>>
>>AFAIK, Eclipse has this feature and it seems to be quite useful.
>>Especially in larger projects or projects depending on many
>>libraries (org., weblogic., javax.* - most of these are not
>>needed for regular business logic coding).
>>
>>r.


0

I think I got what Richard really meant: sometimes there's a library that you need to run your project, and indirect dependency. However, for some reason (let's say, corporate policies) you shouldn't use that library directly.

Hibernate and CGLIB comes to my mind: Hibernate depends on CGLIB, so you should include it in your project to be able to correctly run it, but it's very unlikely that you'll use CGLIB classes directly.

Request #20952[/url] seems to cover part of this situation. The only difference is that #20952 is worried about not including some libraries on the run classpath, and to restrict autocomplete we need exactly the opposite: add libraries to the run classpath only.

0

Sounds like a job for the dependency checker.

If a dependency is marked as illegal, it should not be presented in the list of available classes for that class.

- Tim

0

Marcus, your use case is good, too, just from another perspective.
Here is some additional picture:
- module has assigned some libraries (and depending modules) for compilation
and code validation purposes.
- at runtime, the used libraries may need to be slightly different
(SCR 20952)
- at editing time, on the other side, I'd like to have some
flexibility, too - just to limit packages presented in some UI places
(most of the auto-popups).
Regardless of used libraries, or depending modules.

r.

Marcus Brito wrote:

I think I got what Richard really meant: sometimes there's a library that you
need to run your project, and indirect dependency. However, for some reason
(let's say, corporate policies) you shouldn't use that library directly.

Hibernate and CGLIB comes to my mind: Hibernate depends on CGLIB, so you
should include it in your project to be able to correctly run it, but it's
very unlikely that you'll use CGLIB classes directly.

Request
#20952[/url]
seems to cover part of this situation. The only difference is that #20952 is
worried about not including some libraries on the run classpath, and to
restrict autocomplete we need exactly the opposite: add libraries to the run
classpath only.

0

Please sign in to leave a comment.