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

[Bill Clementson]

On 23 Jan 2007 19:46:18 +0200, Ariel Badichi <abadichi at bezeqint.net> wrote:
> "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'.

Thanks for the explanation - that clears things up for me.

- Bill