...

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)))) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)

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

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 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) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)

"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. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

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. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

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

"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. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen