[slime-devel] slime-repl-kill-input
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. Regards, Irène
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. -T.
"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.
-- With Best Regards, Stas.
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 -- Matthias Koeppe -- http://www.math.ucdavis.edu/~mkoeppe
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
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? -- attila
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?
-- With Best Regards, Stas.
All modes are using a shared key-map for the ease of defining new keys.
i'm not sure what you mean by this. slime-repl-mode does this: (use-local-map slime-repl-mode-map) but somehow (my guess is precedence and/or setup order issue) slime-editing-map gets used instead of slime-repl-mode-map.
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... -- attila
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. -- With best regards, Stas.
* 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. Helmut
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. -- With best regards, Stas.
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... Take two. I've made `slime-repl-map-mode' which uses `slime-repl-mode-map', and I enabled this minor mode after enabling `slime-editing-mode'. I hope this fixes it for good.
-- With best regards, Stas.
participants (7)
-
Attila Lendvai -
Helmut Eller -
Irene DURAND -
Irène Durand
-
Matthias Koeppe -
Stas Boukarev -
Tobias C. Rittweiler