hi!
this is a patch for fuzzy completion made by a friend of mine, Levente Mészáros. he's also subscribed, but he's busy right now, so i'm writing this mail...
see the original thread for a feature list: http://thread.gmane.org/gmane.lisp.slime.devel/4938/focus=5007
also some find definition code has been added since then, works like the fuzzy completion, but jumps to the selected definition instead of replacing the word in the buffer.
we are using it in our daily work for several months now, and although none of us is an experienced elisp guru, it's very very handy from the user side.
i'm sending this patch in the hopes that someone with more elisp experience will review the diff and apply it to the cvs.
stuff that may need attention is the usual C-g abort handling (there's a key binding for this, maybe some catch tag neets to be set up?), and the M-p/M-n history handling (doesn't work for the find-definition part).
and a feature idea right on: the fuzzy completion should not be started when the current input is less then 3 chars long.
hth,
On Mon, 02 Oct 2006 17:12:34 +0200, Attila Lendvai wrote:
hi!
this is a patch for fuzzy completion made by a friend of mine, Levente Mészáros. he's also subscribed, but he's busy right now, so i'm writing this mail...
see the original thread for a feature list: http://thread.gmane.org/gmane.lisp.slime.devel/4938/focus=5007
also some find definition code has been added since then, works like the fuzzy completion, but jumps to the selected definition instead of replacing the word in the buffer.
we are using it in our daily work for several months now, and although none of us is an experienced elisp guru, it's very very handy from the user side.
i'm sending this patch in the hopes that someone with more elisp experience will review the diff and apply it to the cvs.
Hmm, i applied your patch to my local copy and it really broke things:
- Emacs snapshot doesn't like the "<TAB>" keybindings (should be "\t").
- Pressing the tab key in the repl does open the completition window and i'm able to navigate with "up"/"down", but selecting a completition with "enter"/"return" seems to send an "enter" to the repl. With paredit activated this causes havoc since the form most likely isn't completed yet.
Cheers, Ralf Mattes
stuff that may need attention is the usual C-g abort handling (there's a key binding for this, maybe some catch tag neets to be set up?), and the M-p/M-n history handling (doesn't work for the find-definition part).
and a feature idea right on: the fuzzy completion should not be started when the current input is less then 3 chars long.
hth,
i'm sending this patch in the hopes that someone with more elisp
experience
will review the diff and apply it to the cvs.
Hmm, i applied your patch to my local copy and it really broke things:
- Emacs snapshot doesn't like the "<TAB>" keybindings (should be "\t").
these are the things that need attention by more experienced emacs gurus. thanks for the report!
- Pressing the tab key in the repl does open the completition window and
i'm able to navigate with "up"/"down", but selecting a completition with "enter"/"return" seems to send an "enter" to the repl. With paredit activated this causes havoc since the form most likely isn't completed yet.
this is the default behaviour and this is actually a feature. enter and space are rebound while in completion mode so that they insert the selected completion, end the completion mode and trigger the original action mapped to the key.
i have these extra stuff in my init.el:
;; so that they behave as space and enter described above (define-key slime-target-buffer-fuzzy-completions-map (kbd "]") 'slime-fuzzy-select-and-process-event-in-target-buffer) (define-key slime-target-buffer-fuzzy-completions-map (kbd "[") 'slime-fuzzy-select-and-process-event-in-target-buffer)
;; enable the fuzzy completion (define-lisp-key "\t" 'slime-fuzzy-indent-and-complete-symbol nil t) ;; unrelated ielm completion (define-lisp-key "\t" (lambda () (interactive) (ielm-complete-symbol)) nil nil t)
and for reference:
(defun define-lisp-key (key binding &optional except-repl cl-only el-only) (unless el-only (define-key slime-mode-map key binding)) (unless cl-only (define-key emacs-lisp-mode-map key binding)) (unless except-repl (unless el-only (define-key slime-repl-mode-map key binding)) (unless cl-only (define-key ielm-map key binding))))
- Pressing the tab key in the repl does open the completition window and
i'm able to navigate with "up"/"down", but selecting a completition with "enter"/"return" seems to send an "enter" to the repl. With paredit activated this causes havoc since the form most likely isn't completed yet.
The idea here is that the user should not press an extra key to accept the completion (such as enter). So if the pressed key is clealy not part of the symbol being edited (such as space, enter, (, ), etc.) then it fires implicit completion and applies the key afterwards. This might be somewhat strange for the first sight, but it turned out to be very useful.
Still you can have explicit completion by pressing the completion key twice without editing in between (I do it sometimes). Without editing is important here, because otherwise it just updates the completion window which in fact is also very useful. For example when trying to find out the shortest shortcut for a particular symbol.
And of course you can always close the completion window with Esc or C-g or whatever you like.
levy
On Wed, 04 Oct 2006 14:41:44 +0200, Levente Mészáros wrote:
- Pressing the tab key in the repl does open the completition window and
i'm able to navigate with "up"/"down", but selecting a completition with "enter"/"return" seems to send an "enter" to the repl. With paredit activated this causes havoc since the form most likely isn't completed yet.
The idea here is that the user should not press an extra key to accept the completion (such as enter). So if the pressed key is clealy not part of the symbol being edited (such as space, enter, (, ), etc.) then it fires implicit completion and applies the key afterwards. This might be somewhat strange for the first sight, but it turned out to be very useful.
'Yes, i see - i actually kind of like it. I was just missing the documentation i guess ;)
Ok, one quirk: i use paredit-beta in the repl and that seems to break the ( bindings in the completion buffer (typing ( will _not_ complete and only trigger paredit's "()" insertion) - but i can live with that.
Cheers, RalfD
Still you can have explicit completion by pressing the completion key twice without editing in between (I do it sometimes). Without editing is important here, because otherwise it just updates the completion window which in fact is also very useful. For example when trying to find out the shortest shortcut for a particular symbol.
And of course you can always close the completion window with Esc or C-g or whatever you like.
levy
Ok, one quirk: i use paredit-beta in the repl and that seems to break the ( bindings in the completion buffer (typing ( will _not_ complete and only trigger paredit's "()" insertion) - but i can live with that.
Cheers, RalfD
I guess it's because you use a different key binding than we do. The completion buffer uses a separate key map and you should configure the keys there explicitely which you want to have implicit completion. See previous mail from Ati.
(define-key slime-target-buffer-fuzzy-completions-map (kbd "]") 'slime-fuzzy-select-and-process-event-in-target-buffer)
(define-key slime-target-buffer-fuzzy-completions-map (kbd "[") 'slime-fuzzy-select-and-process-event-in-target-buffer)
Actually typing:
( s v u c TAB (
will give me (with the cursor included as |):
(slot-value-using-class (|))
levy
On Wed, 04 Oct 2006 15:37:23 +0200, Levente Mészáros wrote:
Ok, one quirk: i use paredit-beta in the repl and that seems to break the ( bindings in the completion buffer (typing ( will _not_ complete and only trigger paredit's "()" insertion) - but i can live with that.
Cheers, RalfD
I guess it's because you use a different key binding than we do.
Yes, i was aware of that. What i find slightly confusing is the fact that typing a ( while in completition mode will happily insert the character (actually, it 'll insert both ( and ), but that's a feature of paredit) and still stay in completition mode. But I'll have a look at the code as soon as I can spare some time.
Thanks, RalfD
The completion buffer uses a separate key map and you should configure the keys there explicitely which you want to have implicit completion. See previous mail from Ati.
(define-key slime-target-buffer-fuzzy-completions-map (kbd "]") 'slime-fuzzy-select-and-process-event-in-target-buffer)
(define-key slime-target-buffer-fuzzy-completions-map (kbd "[") 'slime-fuzzy-select-and-process-event-in-target-buffer)
Actually typing:
( s v u c TAB (
will give me (with the cursor included as |):
(slot-value-using-class (|))
levy
Yes, i was aware of that. What i find slightly confusing is the fact that typing a ( while in completition mode will happily insert the character (actually, it 'll insert both ( and ), but that's a feature of paredit) and still stay in completition mode. But I'll have a look at the code as soon as I can spare some time.
Actually it should not stay in completion mode if the keymap is configured that way and the completion window should disappear. Otherwise you are just editing the symbol.
Thanks for taking a look at it!
Cheers, levy
Yes, i was aware of that. What i find slightly confusing is the fact that typing a ( while in completition mode will happily insert the character (actually, it 'll insert both ( and ), but that's a feature of paredit) and still stay in completition mode. But I'll have a look at the code as soon as I can spare some tim
this can be configured like this:
(define-key slime-target-buffer-fuzzy-completions-map (kbd ")") 'slime-fuzzy-select-and-process-event-in-target-buffer) (define-key slime-target-buffer-fuzzy-completions-map (kbd "(") 'slime-fuzzy-select-and-process-event-in-target-buffer)
hi,
is there any reason against committing this fuzzy patch?
sorry for bugging, but it's a big diff and managing it with cvs on the other side is a real PITA. i've made other modifications to slime.el and argh... you know what i mean... :)
i'd better don't even bring up switching to darcs, there's enough on my list already... :)
so, i can offer two things in the hope that we can work it out:
- send a fresh diff to the cvs head that applies cleanly - try to answer/fix any questions/issues that would prevent the patch reaching the official repo
additionally i can offer to chop out the slime-search-definition changes, which is basically a fuzzy search definition, to shorten the first pass of the patch and send them later in another pass.
i'm sure Levente, who actually made the new fuzzy gui but has less time generally, is also willing to resolve/answer any questions.
hth,
"Attila Lendvai" attila.lendvai@gmail.com writes:
hi,
is there any reason against committing this fuzzy patch?
applied.
note that this patch changes the behaviour of fuzzy completion. please speak up if there's an issue.
On Fri, Oct 20, 2006 at 02:07:54AM +0200, Marco Baringer wrote:
"Attila Lendvai" attila.lendvai@gmail.com writes:
hi,
is there any reason against committing this fuzzy patch?
applied.
note that this patch changes the behaviour of fuzzy completion. please speak up if there's an issue.
What's in HEAD now can be horked up pretty easily.
1. Make a new buffer. 2. Type "(mvb". 3. Start a fuzzy completion. 4. Close the completion window with C-x 0.
Now anything (and I do mean ANYTHING) typed gets `Wrong type argument: keymapp, "Keymap for slime-target-buffer-fuzze-completions-mod. This will override the key bindings in the target buffer temporarily during completion." I have to kill emacs to recover this.
I think requiring the completions buffer be exited a "special" way is too much of a burdeon to place on the user, especially when it leaves such an ususable state.
-bcd
bdowning@lavos.net (Brian Downing) writes:
I think requiring the completions buffer be exited a "special" way is too much of a burdeon to place on the user, especially when it leaves such an ususable state.
very true. however it was do a bug i introduced when applying the patch and has been fixed.
I think requiring the completions buffer be exited a "special" way is too much of a burdeon to place on the user, especially when it leaves such an ususable state.
very true. however it was do a bug i introduced when applying the patch and has been fixed.
yep, lets switch to darcs... ;)
but anyways, even after that is fixed, there was no kill-buffer-hook. Marco has just committed the fix for it.
and let me advertise that the whole idea was to use it with slime-fuzzy-completion-in-place enabled (which is not the default). Marco added this so the patch is less intrusive.
when it is enabled the focus remains in the original buffer, so you can keep on editing the word and after some edit pressing tab again will update the completion buffer. i'll try adding an auto update feature, where you press tab and then the completion buffer is updated as you edit the word. this needs adding some time limit to the swank side, though...
On Fri, Oct 20, 2006 at 01:11:33PM +0200, Attila Lendvai wrote:
but anyways, even after that is fixed, there was no kill-buffer-hook. Marco has just committed the fix for it.
and let me advertise that the whole idea was to use it with slime-fuzzy-completion-in-place enabled (which is not the default). Marco added this so the patch is less intrusive.
Hmm. I tried enabling this and it doesn't work like I'd expect - typing ( m v b space doesn't get you anything. (Only RET and ')' seem to make it complete anything).
when it is enabled the focus remains in the original buffer, so you can keep on editing the word and after some edit pressing tab again will update the completion buffer. i'll try adding an auto update feature, where you press tab and then the completion buffer is updated as you edit the word. this needs adding some time limit to the swank side, though...
Well, I'll reserve judgement until you're done with it. Right now I find I prefer the old behavior, but then, I wrote the old behavior. :)
It it's still bugging me after you're done I'll find a way to hack the old UI back in as an option.
-bcd
and let me advertise that the whole idea was to use it with slime-fuzzy-completion-in-place enabled (which is not the default).
Marco
added this so the patch is less intrusive.
Hmm. I tried enabling this and it doesn't work like I'd expect - typing ( m v b space doesn't get you anything. (Only RET and ')' seem to make it complete anything).
you need to press at least one TAB to activate it. so it's "(mvb" TAB SPACE
Well, I'll reserve judgement until you're done with it. Right now I
find I prefer the old behavior, but then, I wrote the old behavior. :)
It it's still bugging me after you're done I'll find a way to hack the old UI back in as an option.
hm, i can't really remember the old behaviour but afair the new one only adds extra features when slime-fuzzy-completion-in-place is nil. my memory may trick me, though, because we use it for several months now. in either case our intention was to extend it, not to reform it, so feel free to restore any behaviour you are missing.
"Attila Lendvai" attila.lendvai@gmail.com writes:
hm, i can't really remember the old behaviour but afair the new one only adds extra features when slime-fuzzy-completion-in-place is nil. my memory may trick me, though, because we use it for several months now. in either case our intention was to extend it, not to reform it, so feel free to restore any behaviour you are missing.
let me reiterate that. i had hoped that, when slime-fuzzy-completion-in-place was nil, the _noly_ difference you'd see re the old behaviour is the highlighting of the current selection. feel free to do whatever it takes to make it so.
On Fri, Oct 20, 2006 at 04:41:05PM +0200, Attila Lendvai wrote:
you need to press at least one TAB to activate it. so it's "(mvb" TAB SPACE
I forgot to mention I was hitting my fuzzy-completion key in there (instead of tab). I have C-c C-i bound to slime-fuzzy-complete-symbol. So I type (with in-place enabled):
( m v b C-c C-i Space
and get nothing. But:
( m v b C-c C-i )
gets me "(multiple-value-bind)".
I guess I'd like to know the behavior that's expected with in-place t, so I don't break anything. :)
It it's still bugging me after you're done I'll find a way to hack the old UI back in as an option.
hm, i can't really remember the old behaviour but afair the new one only adds extra features when slime-fuzzy-completion-in-place is nil. my memory may trick me, though, because we use it for several months now. in either case our intention was to extend it, not to reform it, so feel free to restore any behaviour you are missing.
Okay, I'll do so. A short list is:
* Target buffer is put into target-buffer-mode even when in-place is nil. * Target buffer no longer "live-updates" the completion when in-place is nil. * Hitting RET in the completion buffer inserts a RET into the target buffer when in-place is nil. (And SPACE inserts a space instead of paging down as per the usual emacs read-only buffer behavior - I may keep this, though...)
-bcd
-
Attila Lendvai -
bdowning＠lavos.net -
Levente Mészáros -
Marco Baringer -
Ralf Mattes