"Tobias C. Rittweiler" tcr@freebits.de writes:

Irène Durand idurand@labri.fr writes:

...

Hello,

In SLIME, I was used to use the key C-c-C-u which was bound to the command slime-repl-kill-input

In recent versions, this command exists but is no longer bound to any key; (it is however accessible from the REPL menu). And the key C-c C-u is bound to the command slime-undefine-function (fmakunbound) which confuses me each time I hit C-c-C-u.

Of course, I can myself make the binding to some unused key, but I think that such a useful and frequenlty used command should be, by default, bound to a convenient key.

What binding do you suggest?

Perhaps there's even a standard Emacs key binding which is equivalent to

(kill-region (point) (point-max))

So you can use C-M-a to jump to the start of the REPL, and then issue that keybinding if it exists -- obliterating the need for slime-repl-kill-input.

Binding to slime-repl-kill-input isn't gone, it's just shadowed by slime-editing-mode.

Matthias Koeppe a écrit :

On Mon, Jan 11, 2010 at 6:32 AM, Tobias C. Rittweiler tcr@freebits.de wrote:

...

Irène Durand idurand@labri.fr writes:

...

In SLIME, I was used to use the key C-c-C-u which was bound to the command slime-repl-kill-input

Perhaps there's even a standard Emacs key binding which is equivalent to

(kill-region (point) (point-max))

So you can use C-M-a to jump to the start of the REPL, and then issue that keybinding if it exists -- obliterating the need for slime-repl-kill-input.

It would be great to have C-c C-u available for slime-repl-kill-input. It's an important comint.el key binding that many users (including myself) use all the time. We should try to keep the SLIME REPL as close as possible to comint.el behavior.

I would think the use of slime-undefine-function is much rarer, so we could move that to a different keybinding.

Matthias

I completly agree with Matthias. I was used to use C-c C-u during my Lisp courses and I got trapped when suddenly the key started to call fmakunbound!

Irène

Attila Lendvai attila.lendvai@gmail.com writes:

i looked into why the editing keys take precedence over the repl bindings, but i'm lacking the knowledge of how keymaps and minor/major modes interact.

the problem is most probably around defun slime-repl-mode in slime-repl.el.

is has a (use-local-map slime-repl-mode-map), but still somehow the slime-editing-mode gets precedence.

fuzzy completion had a similar issue which i've resolved with the following code snipplet:

(setf minor-mode-map-alist (stable-sort minor-mode-map-alist (lambda (a b) (eq a 'slime-fuzzy-target-buffer-completions-mode)) :key #'car))

...but slime-repl-mode is not a minor mode, so this trick can not help there.

thoughts?

All modes are using a shared key-map for the ease of defining new keys. Maybe it's better to have a function which will define a keybinding for all relevant slime modes?

On Thu, Jan 14, 2010 at 5:38 PM, Attila Lendvai attila.lendvai@gmail.com wrote:

...

Maybe it's better to have a function which will define a keybinding for all relevant slime modes?

imho that would lead far and duplicate the logic keymaps, modes and their inheritance provide in emacs.

the current setup with a tree of keymaps inheriting from each other is flexible enough. it's just the repl mode seems to misbehave for some reason...

I've achieved that by setting slime-repl-mode-map's parent to (append slime-editing-map lisp-mode-map) and not using slime-editing-mode in slime-repl-mode. This is committed in CVS.

On Thu, Jan 14, 2010 at 7:57 PM, Helmut Eller heller@common-lisp.net wrote:

• Stas Boukarev [2010-01-14 16:55+0100] writes:

...

I've achieved that by setting slime-repl-mode-map's parent to (append slime-editing-map lisp-mode-map) and not using slime-editing-mode in slime-repl-mode. This is committed in CVS.

Funny that it works.  In XEmacs keymaps aren't lists but some opaque structure, so append doesn't work there.  But XEmacs has set-keymap-parents which allows multiple parents.  That could be used.

Copying the first argument is also not quite what we want, because (define-key slime-editing-map ...) might no longer update the copy.  I haven't tested it, though.

I understood why it works. I've tested it on "\C-c ..." bindings, C-c is a prefix key, so it's stored in the keymap as (3 keymap ... bindings) and therefore it's shared. So, my solution isn't very good.