Re: M-x mystery

[Silvio Levy]

Hi Drew, I'll answer this question first:

> (Also, why are you doing `make-keymap' here?  Why is that necessary?  

It is vip that does make-keymap. I simply boiled down wha vip.el is
doing to the minimum code that causes the problem. If I just reported
"icicle messes up vi emulation mode" I couldn't expect someone to look
at the vi emulation code. So I distilled out of that the problem I'm
reporting. I can reproduce it in 6 lines. Let me rewrite them here
without mentioning vip at all:

(defun doit ()
  "run test"
  (interactive)
  (defvar my-map (make-keymap))
  (define-key my-map "\e" 'kill-line)
  (use-local-map my-map))

Now let me address this:
> `M-x' is typically the same as `ESC x' (it is translated from `ESC x')

I should have written alt-x,  Surely that's distinct from ESC x. 

When I start a fresh emacs -q, if I type <help> k <alt>x, emacs
reports that M-x is bound to execute-extended-command. Now suppose I
go into a buffer containing the code above, and do C-x C-e at the end
of it. Then after M-x doit<RET>, it seems that <alt>x is not even
recognized anymore: when I type <help> k <alt>x, emacs reports that
Escape is bounded to kill-line,

And that's what I don't understand. It's one thing for <ESC> x to be
treated as M-x because some people lack that alt key, but for emacs to
*convert* the keycode <alt>x to <ESC> x seems to me like poor design.

Why is it poor design? This is where I need to explain my motivation
for rebinding <ESC>.

Vi makes a distinction between insert mode and command mode. The fact
that (standard) emacs treats undecorated keys as self-insertion is in
my view its only major design flaw, and one that is neatly remedied by
vi emulation. In vi, undecorated keys are used for all sorts of
purposes, like moving around the file, which avoid having to reach for
the control key for every damn thing. Naturally, when you're adding
text you want these same keys to self-insert; ergo, there is an insert
mode. And in insert mode, ESC means "get me out of insert mode".

So that's why vip rebinds ESC (when in insert mode). Icicle disables
that. So I was trying to rebind vip-change-to-vi-mode (get out of
insert mode) away from ESC to, say, <F1>, which is close to ESC on the
keyboard -- close enough that I can live with it. But nothing I did
worked.

And in trying to figure out why, I'm frustrated by the fact that
<alt>x is disabled by vip's rebinding of ESC. And **that's** the
problem I'm trying to solve first. I have a hard time imagining that
emacs cannot be persuaded to recognize <alt>x separately from <ESC>.

Best,

Silvio


> > in trying to debug some bad interactions between vip.el (VI emulation)
> > and icicles, I've come against an obstable I can't surmount: M-x
> > sometimes ceases to be M-x and becomes instead ESC-x.  
> > 
> > Minimal example: I run "emacs -q -l foo.el" where foo.el 
> > contains this code:
> > (defun doit ()
> >   "run test"
> >   (interactive)
> >   (defvar vip-mode-map (make-keymap))
> >   (define-key vip-mode-map "\e" 'kill-line)
> >   (use-local-map vip-mode-map))
> > 
> > Then I into a scratch buffer and type M-x doit<RET> -- so far so good.
> > After that, when I type M-x the behavior, it is as if I had typed ESC
> > and x: the current line is killed and an x is inserted.
> > Any ideas about what I'm doing wrong?
> 
> `M-x' is typically the same as `ESC x' (it is translated from `ESC x').  If 
> you
> redefine `ESC' as a command (`kill-line') then it can no longer continue to 
> act
> as a prefix key.  So both `M-x' and `ESC x' are then undefined.
> 
> (Also, why are you doing `make-keymap' here?  Why is that necessary?  Why not
> just invoke `doit' after you have loaded Vip, so the keymap will be already
> defined?)
> 
> FYI: You can customize the key that Icicles uses to invoke
> `icicle-execute-extended-command' (by default it is `M-x').  Just customize
> option `icicle-top-level-key-bindings', changing the entry for that command.
> 
> Anyway, I tried to follow your recipe.  It seems incomplete.  You start with
> `emacs -q`, which is good, but you do not show where/when you load vip.el[c] 
> or
> Icicles, and you do not show where/when you turn on Vip mode or Icicles mode.
> Sometimes the load or mode-invocation order can matter (but it should not).
> 
> When I do `emacs -Q', then load vip.el, then evaluate the code above and do 
> `M-x
> doit', then load Icicles and turn on Icicle mode, I do not see the behavior 
> you
> describe.  If I then turn on Vip mode (using `M-x vip-mode' and answering `n' 
> to
> inhibiting startup msg), I still do not see that behavior.  If I toggle Icicle
> mode off then on again I still do not see that behavior.  And I don't see any
> difference if I turn on vip-mode before Icicle mode, etc.  The order does not
> seem to matter.
> 
> `C-h k' says `M-x' and `ESC x' are undefined.  But they both seem to work
> normally, invoking `icicle-execute-extended-command' in Icicle mode and
> `execute-extended-command' when I turn off Icicle mode!  Yet looking at
> `vip-mode-map' I see that it has `ESC' defined as `kill-line'.  But `C-h w
> kill-line' does not list `ESC' as one of the bindings.  I get the impression
> that I am not really in Vip mode (?).  And yet I see `Vi:' in the mode line.
> But `C-h m' does not mention Vip at all (?).
> 
> I tried toggling Vip mode using `M-x vip-mode', but I still see `Vi:' in the
> mode line. I know nothing about Vip, so I'm probably not turning it off and on
> correctly.  I took a quick look at the Vip doc, but it wasn't very helpful,
> IMHO.
> 
> Please send me a more complete recipe, mentioning also your Emacs version. We
> can take this off list. But if someone else familiar with Vip can help, please
> post.
>