Hello,
Apparently, C-M-q is undefined in Lisp Slime buffers (SLIME version 2007-01-20). Is this intentional? I hope not... :)
Ariel
On Mon Jan 22, 2007 at 01:51:17AM +0200, Ariel Badichi wrote:
Hello,
Apparently, C-M-q is undefined in Lisp Slime buffers (SLIME version 2007-01-20). Is this intentional? I hope not... :)
Ariel
I don't know if it is intentional or not. What is it you think it should do? I just *looked it up* in the Index to Key Bindings and it doesn't appear to be bound to anything.
[The emphasis is for those who want to do away with the index to key bindings]. ;-)
--Jeff
Apparently, C-M-q is undefined in Lisp Slime buffers (SLIME version
I don't know if it is intentional or not. What is it you think it should do? I just *looked it up* in the Index to Key Bindings and it doesn't appear to be bound to anything.
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
[The emphasis is for those who want to do away with the index to key bindings]. ;-)
Ungrateful wretches those nameless people, eh! ;-)
- Bill
Hello,
"Bill Clementson" billclem@gmail.com writes:
Apparently, C-M-q is undefined in Lisp Slime buffers (SLIME version
I don't know if it is intentional or not. What is it you think it should do? I just *looked it up* in the Index to Key Bindings and it doesn't appear to be bound to anything.
(Like Bill said, it should be bound to the function `indent-sexp'.)
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
It isn't bound to anything. On further investigation, however, that only happens when using the slime scratch buffer. The function `slime-scratch-buffer' uses a special keymap in that case, which seems to be the reason for this problem, but I don't know how to fix it yet.
[The emphasis is for those who want to do away with the index to key bindings]. ;-)
Ungrateful wretches those nameless people, eh! ;-)
- Bill
Ariel
"Bill Clementson" billclem@gmail.com writes:
Apparently, C-M-q is undefined in Lisp Slime buffers (SLIME version
I don't know if it is intentional or not. What is it you think it should do? I just *looked it up* in the Index to Key Bindings and it doesn't appear to be bound to anything.
(Like Bill said, it should be bound to the function `indent-sexp'.)
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
It isn't bound to anything. On further investigation, however, that only happens when using the slime scratch buffer. The function `slime-scratch-buffer' uses a special keymap in that case, which seems to be the reason for this problem, but I don't know how to fix it yet.
Hmm, fixing it is easy - just add the binding to the existing slime-define-keys statement: (slime-define-keys slime-scratch-mode-map ("\C-j" 'slime-eval-print-last-expression) ("\C-\M-q" 'indent-sexp))
However, I can't see why "C-M-q" isn't bound in the slime-scratch-buffer. When I'm in the slime scratch buffer, I can do "C-h b" and it shows that C-M-q is bound to indent-sexp. However, if I do a "C-h k C-M-q" in the slime scratch buffer it says that it isn't bound!!
weird.
- Bill
Hello,
"Bill Clementson" billclem@gmail.com writes:
"Bill Clementson" billclem@gmail.com writes:
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
It isn't bound to anything. On further investigation, however, that only happens when using the slime scratch buffer. The function `slime-scratch-buffer' uses a special keymap in that case, which seems to be the reason for this problem, but I don't know how to fix it yet.
Hmm, fixing it is easy - just add the binding to the existing slime-define-keys statement: (slime-define-keys slime-scratch-mode-map ("\C-j" 'slime-eval-print-last-expression) ("\C-\M-q" 'indent-sexp))
This looks like treating a symptom rather than the cause, and there may be more missing bindings.
It also assumes `C-M-q' has not been customized and is therefore supposed to be bound to `indent-sexp', which isn't necessarily true. But I don't think many will complain about this.
However, I can't see why "C-M-q" isn't bound in the slime-scratch-buffer. When I'm in the slime scratch buffer, I can do "C-h b" and it shows that C-M-q is bound to indent-sexp. However, if I do a "C-h k C-M-q" in the slime scratch buffer it says that it isn't bound!!
Hmm, it isn't described here.
weird.
Indeed.
- Bill
Ariel
Hi,
Ariel Badichi abadichi@bezeqint.net writes:
Hello,
"Bill Clementson" billclem@gmail.com writes:
"Bill Clementson" billclem@gmail.com writes:
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
I compared two slime.el-files: one quite old with C-M-q active in *slime-scratch* and the current one.
Now, the old creation of the keymap for that buffer used lisp-mode-map:
(defvar slime-scratch-mode-map) (setq slime-scratch-mode-map (make-sparse-keymap)) (set-keymap-parent slime-scratch-mode-map lisp-mode-map)
whereas the new creation uses slime-mode-map:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map slime-mode-map) map))
and slime-define-keys does not create a binding for indent-sexp.
Is this the correct analysis? I am not very familiar with slime.el.
Regards, Stefan
PS: As for the differences in C-h k C-M-q and C-h m: I have seen this in the past but never searched for the reason since I happen to use C-h m only very rarely. I seem to remember that I also saw keybindings in menu entries which were not correct.
PPS: Ah, and this is speaking for XEmacs/Gentoo Linux/CVS HEAD Slime
Hello,
Stefan Kamphausen skampi@gmx.net writes:
"Bill Clementson" billclem@gmail.com writes:
I have updated to SLIME 2007-01-20 and when I press C-h k C-M-q I see that C-M-q is bound to indent-sexp. I don't remember it being bound to anything else (but I may be wrong). Ariel, are you saying that C-M-q is not bound to anything or that it has the wrong binding?
I compared two slime.el-files: one quite old with C-M-q active in *slime-scratch* and the current one.
Now, the old creation of the keymap for that buffer used lisp-mode-map:
(defvar slime-scratch-mode-map) (setq slime-scratch-mode-map (make-sparse-keymap)) (set-keymap-parent slime-scratch-mode-map lisp-mode-map)
whereas the new creation uses slime-mode-map:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map slime-mode-map) map))
and slime-define-keys does not create a binding for indent-sexp.
Is this the correct analysis? I am not very familiar with slime.el.
I think it's correct, and this seems to have fixed it:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parents map (list slime-mode-map lisp-mode-map)) map))
Regards, Stefan
PS: As for the differences in C-h k C-M-q and C-h m: I have seen this in the past but never searched for the reason since I happen to use C-h m only very rarely. I seem to remember that I also saw keybindings in menu entries which were not correct.
PPS: Ah, and this is speaking for XEmacs/Gentoo Linux/CVS HEAD Slime
-- Stefan Kamphausen --- http://www.skamphausen.de a blessed +42 regexp of confusion (weapon in hand) You hit. The format string crumbles and turns to dust.
Ariel
On Tue Jan 23, 2007 at 02:59:54PM +0200, Ariel Badichi wrote:
I think it's correct, and this seems to have fixed it:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parents map (list slime-mode-map lisp-mode-map)) map))
I will update the documentation accordingly.
-Jeff
Hello,
Jeffrey Cunningham jeffrey@cunningham.net writes:
On Tue Jan 23, 2007 at 02:59:54PM +0200, Ariel Badichi wrote:
I think it's correct, and this seems to have fixed it:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parents map (list slime-mode-map lisp-mode-map)) map))
I will update the documentation accordingly.
Not just yet :)
I realized, while taking a shower, that there's something fishy there; I didn't know too much about keymaps, so I thought slime-mode-map should already have lisp-mode-map as its parent, and so wondered why this was needed. I read bits of the manual and learned about global keymaps, minor mode keymaps, and local keymaps. The conclusion I ended up with is this: the parent keymap shouldn't have been slime-mode-map, but lisp-mode-map, and only that. This is because slime-mode-map is already active because of the Slime minor mode, yet lisp-mode-map is a local map. I tested this by evaluating (current-local-map) in the SLIME scratch buffer and in an ordinary Lisp Slime buffer, and the results seem to confirm this. (Showers do that, y'know.)
So a better fix is:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map lisp-mode-map) map))
-Jeff
Ariel
So a better fix is:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map lisp-mode-map) map))
without knowing too much about keymaps, minor/major modes and their interactions... (so take it with a piece of salt...) but how about (set-keymap-parent slime-mode-map lisp-mode-map)?
if that works as expected, then that may be a more general solution.
just a note: in my local copy some time ago i've dropped all those dolist's that directly set the keys in the various slime maps (sldb-mode-map, slime-xref-mode-map, slime-repl-mode-map) and replaced them with set-keymap-parent calls. until now everything works as expected (by me), but it needs more time or someone with more experience with modes and keymaps to commit it.
Hello,
"Attila Lendvai" attila.lendvai@gmail.com writes:
So a better fix is:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map lisp-mode-map) map))
without knowing too much about keymaps, minor/major modes and their interactions... (so take it with a piece of salt...) but how about (set-keymap-parent slime-mode-map lisp-mode-map)?
Hmm. Lisp is a major mode, so it sets up lisp-mode-map as a local keymap. Slime is a minor mode, and it can be used with major modes other than Lisp, though that doesn't seem terribly useful. Why should Slime be a keymap hog and absorb lisp-mode-map into slime-mode-map? Especially when in the general case (non-scratch Lisp Slime buffers) lisp-mode-map bindings are already active, so there'll be duplication of bindings, unless you change the local keymap but that seems perverse. The SLIME scratch buffer is a special case, and needs its own local keymap anyway. Since it gets created with a Lisp major mode we can reasonably say that its local keymap should be based on lisp-mode-map. It would also change the order of key lookup; if someone comes up with another minor mode that is supposed, say, to override some Lisp mode keybindings, it could conflict with Slime then.
if that works as expected, then that may be a more general solution.
just a note: in my local copy some time ago i've dropped all those dolist's that directly set the keys in the various slime maps (sldb-mode-map, slime-xref-mode-map, slime-repl-mode-map) and replaced them with set-keymap-parent calls. until now everything works as expected (by me), but it needs more time or someone with more experience with modes and keymaps to commit it.
--
- 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)
Ariel
On 23 Jan 2007 17:03:25 +0200, Ariel Badichi abadichi@bezeqint.net wrote:
Hello,
"Attila Lendvai" attila.lendvai@gmail.com writes:
So a better fix is:
(defvar slime-scratch-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map lisp-mode-map) map))
without knowing too much about keymaps, minor/major modes and their interactions... (so take it with a piece of salt...) but how about (set-keymap-parent slime-mode-map lisp-mode-map)?
Hmm. Lisp is a major mode, so it sets up lisp-mode-map as a local keymap. Slime is a minor mode, and it can be used with major modes other than Lisp, though that doesn't seem terribly useful. Why should Slime be a keymap hog and absorb lisp-mode-map into slime-mode-map? Especially when in the general case (non-scratch Lisp Slime buffers) lisp-mode-map bindings are already active, so there'll be duplication of bindings, unless you change the local keymap but that seems perverse. The SLIME scratch buffer is a special case, and needs its own local keymap anyway. Since it gets created with a Lisp major mode we can reasonably say that its local keymap should be based on lisp-mode-map. It would also change the order of key lookup; if someone comes up with another minor mode that is supposed, say, to override some Lisp mode keybindings, it could conflict with Slime then.
What's confusing for me is that (if I do a "C-h m" in the SLIME scratch buffer) both lisp mode and slime mode are shown as being active in the SLIME scratch buffer. And, (again, if you do "C-h m") the "C-M-q" key chord is shown as being bound to indent-sexp in lisp mode but that it is being "shadowed". But there is no alternative binding for C-M-q. So, presumably some other minor mode must be removing the "C-M-q" binding? But, slime-scratch-buffer does the following: (with-current-buffer (get-buffer-create "*slime-scratch*") (lisp-mode) (use-local-map slime-scratch-mode-map) (slime-mode t) (current-buffer))
so, I would have thought that the same bindings that are in effect for lisp-mode and slime-mode would also be in effect for the slime-scratch buffer (with the addition of any keys that were added to slime-scratch-mode-map - only C-j at the moment). I don't see what could be "shadowing" the C-M-q binding in lisp-mode.
- Bill
"Bill Clementson" billclem@gmail.com writes:
On 23 Jan 2007 17:03:25 +0200, Ariel Badichi abadichi@bezeqint.net wrote:
Hmm. Lisp is a major mode, so it sets up lisp-mode-map as a local keymap. Slime is a minor mode, and it can be used with major modes other than Lisp, though that doesn't seem terribly useful. Why should Slime be a keymap hog and absorb lisp-mode-map into slime-mode-map? Especially when in the general case (non-scratch Lisp Slime buffers) lisp-mode-map bindings are already active, so there'll be duplication of bindings, unless you change the local keymap but that seems perverse. The SLIME scratch buffer is a special case, and needs its own local keymap anyway. Since it gets created with a Lisp major mode we can reasonably say that its local keymap should be based on lisp-mode-map. It would also change the order of key lookup; if someone comes up with another minor mode that is supposed, say, to override some Lisp mode keybindings, it could conflict with Slime then.
What's confusing for me is that (if I do a "C-h m" in the SLIME scratch buffer) both lisp mode and slime mode are shown as being active in the SLIME scratch buffer.
What `C-h m' shows is an instantiation of generic description templates contained in the modes. It only looks for keybindings for the specific functions names found in these templates. The two modes are indeed active, but the keybindings are wrong.
And, (again, if you do "C-h m") the "C-M-q" key chord is shown as being bound to indent-sexp in lisp mode but that it is being "shadowed". But there is no alternative binding for C-M-q. So, presumably some other minor mode must be removing the "C-M-q" binding? But, slime-scratch-buffer does the following: (with-current-buffer (get-buffer-create "*slime-scratch*") (lisp-mode) (use-local-map slime-scratch-mode-map) (slime-mode t) (current-buffer))
so, I would have thought that the same bindings that are in effect for lisp-mode and slime-mode would also be in effect for the slime-scratch buffer (with the addition of any keys that were added to slime-scratch-mode-map - only C-j at the moment). I don't see what could be "shadowing" the C-M-q binding in lisp-mode.
- Bill
Like I said, Lisp is a major mode, and it uses a local keymap for its keybindings. The code above replaces the local keymap with its own. The keymap used is essentially the slime-mode-map plus some keybindings specific to SLIME scratch buffer, but no keybindings from lisp-mode-map. The effect is that there is duplication of slime-mode-map keybindings (one such keymap in minor mode keymaps, the other in the local keymap), and absence of lisp-mode-map keybindings.
A non-scratch Lisp Slime buffer:
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: lisp-mode-map
A scratch Lisp Slime buffer (before fix):
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: slime-scratch-mode-map (slime-mode-map plus scratch-specific keybindings)
A scratch Lisp Slime buffer (after fix):
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: slime-scratch-mode-map (lisp-mode-map plus scratch-specific keybindings)
You can inspect these yourself by evaluating the functions `current-global-map' (irrelevant in this case), `current-minor-mode-maps', and `current-local-map'.
Ariel
On 23 Jan 2007 19:46:18 +0200, Ariel Badichi abadichi@bezeqint.net wrote:
"Bill Clementson" billclem@gmail.com writes:
On 23 Jan 2007 17:03:25 +0200, Ariel Badichi abadichi@bezeqint.net wrote:
Hmm. Lisp is a major mode, so it sets up lisp-mode-map as a local keymap. Slime is a minor mode, and it can be used with major modes other than Lisp, though that doesn't seem terribly useful. Why should Slime be a keymap hog and absorb lisp-mode-map into slime-mode-map? Especially when in the general case (non-scratch Lisp Slime buffers) lisp-mode-map bindings are already active, so there'll be duplication of bindings, unless you change the local keymap but that seems perverse. The SLIME scratch buffer is a special case, and needs its own local keymap anyway. Since it gets created with a Lisp major mode we can reasonably say that its local keymap should be based on lisp-mode-map. It would also change the order of key lookup; if someone comes up with another minor mode that is supposed, say, to override some Lisp mode keybindings, it could conflict with Slime then.
What's confusing for me is that (if I do a "C-h m" in the SLIME scratch buffer) both lisp mode and slime mode are shown as being active in the SLIME scratch buffer.
What `C-h m' shows is an instantiation of generic description templates contained in the modes. It only looks for keybindings for the specific functions names found in these templates. The two modes are indeed active, but the keybindings are wrong.
And, (again, if you do "C-h m") the "C-M-q" key chord is shown as being bound to indent-sexp in lisp mode but that it is being "shadowed". But there is no alternative binding for C-M-q. So, presumably some other minor mode must be removing the "C-M-q" binding? But, slime-scratch-buffer does the following: (with-current-buffer (get-buffer-create "*slime-scratch*") (lisp-mode) (use-local-map slime-scratch-mode-map) (slime-mode t) (current-buffer))
so, I would have thought that the same bindings that are in effect for lisp-mode and slime-mode would also be in effect for the slime-scratch buffer (with the addition of any keys that were added to slime-scratch-mode-map - only C-j at the moment). I don't see what could be "shadowing" the C-M-q binding in lisp-mode.
- Bill
Like I said, Lisp is a major mode, and it uses a local keymap for its keybindings. The code above replaces the local keymap with its own. The keymap used is essentially the slime-mode-map plus some keybindings specific to SLIME scratch buffer, but no keybindings from lisp-mode-map. The effect is that there is duplication of slime-mode-map keybindings (one such keymap in minor mode keymaps, the other in the local keymap), and absence of lisp-mode-map keybindings.
A non-scratch Lisp Slime buffer:
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: lisp-mode-map
A scratch Lisp Slime buffer (before fix):
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: slime-scratch-mode-map (slime-mode-map plus scratch-specific keybindings)
A scratch Lisp Slime buffer (after fix):
Global keymap: ... Minor mode keymaps: ..., slime-mode-map, ... Local keymap: slime-scratch-mode-map (lisp-mode-map plus scratch-specific keybindings)
You can inspect these yourself by evaluating the functions `current-global-map' (irrelevant in this case), `current-minor-mode-maps', and `current-local-map'.
Thanks for the explanation - that clears things up for me.
- Bill
-
Ariel Badichi -
Attila Lendvai -
Bill Clementson -
Jeffrey Cunningham -
Stefan Kamphausen