Two additional suggestions:

jde-import-import takes a fully qualified classname.
If a user types a fully qualified name, he or she
usually wants exactly that class to be imported.
Therefore, jde-import-import should not exclude classes at all.

In order to allow classes to be imported which would be excluded
by jde-import-exclude-imports, it would be desirable to disable
excluding temporarily. This could be done by a prefix argument.
Such a feature would be useful for jde-import-all and for jde-import-find-and-import.
Once implemented, one could import xyz.String by typing
C-u C-c C-v C-z String RET even if synonyms of java.lang classes
would be excluded by jde-import-exclude-imports.


Thoughts?

Regards,

Martin

Martin Schwamberger wrote:
Paul Kinnucan wrote:

Petter Måhlén writes:
> Hi Paul,
> > The patched jde-import.el is attached. Basically, what it does is to create
> the list of fully expanded potential classes to import for each token, as
> before. Then, it checks if any of the classes belongs to java.lang or the
> current package, and if so, excludes all of them.
Hi Petter,


This seems to be a rather blunt solution to the problem of synonyms for
java.lang classes. What if I really do want xyz.String instead of java.lang.String?

Hi Paul,

I like Petter's idea.
The solution he published several weeks ago has the drawback,
that it is hard-coded and can't be customized by users.
But the feature itself is quite useful.

What about the following improvement:

  jde-import-excluded-packages will be replaced by:

  (defcustom jde-import-excluded-classes
    '(("^bsh\\..*" . nil)
      ("^java\\.lang\\.[^.]*$" . t)
      ("^sun\\..*" . nil)
      ("^com\\.sun\\..*" . nil)
      (jde-import-exclude-current-package . t))
    "..."
    :group 'jde-project
    :type '(repeat
            (cons :tag "Exclude rule"
                  (choice :tag "Exclude test"
                          (regexp :tag "Regexp")
                          (function :tag "Exclude test function"))
                  (boolean :tag "Exclude synonyms"))))

  The car of each cons has the same meaning as the elements in
  jde-import-excluded-packages. The cdr controls whether all
  synonyms of matching classes should be excluded or not.

  jde-import-exclude-imports uses jde-import-excluded-classes
  and does the whole job.

As a side effect, this would ensure, that jde-import-import
excludes the same classes as jde-import-all.

The obvious drawback is that this change would break existing customizations.
Nevertheless, I think it's worth to think about it.


May I suggest the following solution. Suppose the JDEE includes, in
addition to jde-import-exclude-packages, jde-import-exclude-classes?
The new variable allows you to exclude individual classes without
excluding an entire package. In particular, you coulde exclude
xyz.String and java.lang.String without exculding other classes
from the xyz package.


It's already possible to exclude single classes with jde-import-excluded-packages. Only the name of the variable is a bit confusing. That's the reason why I used the name jde-import-excluded-classes in the above example ;-)

Regards,

Martin


Paul



Reply via email to