Found another little nit to pick. I have a class named "Task", and when I run jde-import-all for that class, I am prompted to import some class named sun.something.Task. I am not enough of an elisp person to see how, but maybe jde-import-all-expand-strip-exclude should exclude the current class as well?
I like your suggestion for the key bindings in the dialog as well, that would be perfect. / Petter > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Phillip Lord > Sent: den 12 mars 2004 15:21 > To: [EMAIL PROTECTED] > Subject: Re: jde-import-all > > > >>>>> "Petter" == Petter M�hl�n <[EMAIL PROTECTED]> writes: > > Petter> I've tested this a bit now, and I really like it. I have > Petter> found one slight problem, and I have one request for a > Petter> possible improvement: > > Petter> 1. It doesn't detect the need to import List with the > Petter> following class: > Petter> ---- public class Hej { > Petter> public Hej() { } > > Petter> public List hejsan() { } > Petter> } ---- > > Petter> I guess it doesn't check for return types? It may seem like > Petter> a non-valid use case, but in my case, I had a method that > Petter> instantiated a LinkedList but with a signature returning a > Petter> List. > > > No this is entirely valid. I do this myself a lot. You are right it is > missing those. I will try and work up a good regexp for this. > > > Petter> 2. If possible, and this is something that I have always > Petter> wanted for the > Petter> dialogs, I would like the cursor to be positioned on the Ok > Petter> button by default. That way, I can just hit return to > Petter> confirm the selection. That probably is only valid in the > Petter> "one-hit" case here, not when the user actually has to go > Petter> through and select lots of stuff, so it's not really a big > Petter> deal. > > I think that this is a valid issue and have thought about it myself. > If you look at code for creating a dialog though you get this... > > (defmethod efc-dialog-show ((this efc-dialog)) > > ;; stuff chopped > > > > (use-local-map widget-keymap) > (widget-setup) > > ;; Position cursor over OK button. > ;; (forward-line 0) > > (goto-char (point-min)) > > (pop-to-buffer (oref this buf))) > > > In otherwords this functionality was there at one point but its been > commented out. I'm not sure why, but I think that there is a > usability issue here. If the dialog box is long which is distinctly > possible with the import dialog, the prompt line at the top of the > dialog may end up off screen. > > I can think of two possible solution. First this method is changed to > enable the programmer to put the "ok" and "cancel" but at the > top. This way its a simple tab to get to the ok button. > > Alternatively, and I think a better option, would be to set the dialog > in a specialised mode to add some extra keybindings to run the "ok" or > "cancel" functionality where ever point is. This way you could click > as many buttons as you choose and then do "C-cC-c" or similar to > confirm, and maybe "C-cC-k" to kill the dialog box. I think is > probably the easier solution. > > But it requires changes to core JDE which is why I didn't do it in the > short term. > > Cheers > > Phil >
