[slime-devel] Re: C-M-q not working in SLIME 2007-01-20

[Ariel Badichi]

"Bill Clementson" <billclem at gmail.com> writes:

> On 23 Jan 2007 17:03:25 +0200, Ariel Badichi <abadichi at 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