Re: Jde-import.el
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
Re: Jde-import.el
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
SV: Jde-import.el
Oops, forgot to copy the list for the below response: I am not quite sure that I agree that it is a blunt solution. The reason is that according to the specification, classes from two packages are always available: those from the current package and from java.lang. This means that unless you explicitly specify that another x.y.String class should be used, the one from java.lang will be used. So in my opinion, the solution only does what the compiler does anyway. It uses classes imported implicitly if possible, and tries to import them explicitly otherwise. I think that more than 99.9% (or even 99.99%) of all uses of String are java.lang.String, so it is also better to optimise for that case than for the rare one when another String is needed. And the same probably goes for most of the classes in java.lang. I think that a behaviour similar to that is more intuitive than requiring users to configure some variables since only power-users are likely to be aware of the existence of those variables, and if the default behaviour is unexpected, it will be ticking people off. But although I think the behaviour is right, I am not sure about the implementation, which most likely could be better. Does that make sense? / Petter -Ursprungligt meddelande- Från: Paul Kinnucan [mailto:[EMAIL PROTECTED] Skickat: den 8 juli 2004 07:00 Till: Petter Måhlén Kopia: [EMAIL PROTECTED] Ämne: Jde-import.el 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? 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. Paul
Jde-import.el
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? 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. Paul
