>>>>> "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
