Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.emacs
Subject: Re: Keyboard macros (was: Re: Copy From Above?)
Message-ID: <36476@think.UUCP>
Date: 17 Feb 89 03:40:55 GMT
References: <690026@hpsemc.HP.COM> <36077@bbn.COM> <50884@yale-celray.yale.UUCP>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 29

In article <50884@yale-celray.yale.UUCP> Ram-Ashwin@cs.yale.edu (Ashwin Ram) writes:
>I wish there was a way of "decompiling" the macro, i.e., a function that
>inserted, not the raw keystrokes, but the names of the commands that those
>keytrokes were bound to.  Keyboard macros are neat for simple things, but if
>you want to modify one you're out of luck.

It's extremely hard to do this right.  Multics Emacs had such a
feature, but it made lots of mistakes.  The problem is that it's
difficult to know the binding of a keystroke, because previous
commands might have caused key bindings to change.  For example, after
a "c-x b return" command, what is the "d" key bound to?  If the
previous buffer at the time of invocation is a Dired buffer it would
be bound to dired-flag-file-deleted, but in other cases it would be
self-insert-command.

Another problem comes up if the command reads input from the
minibuffer.  The macro compiler would have to know that it does this,
figure out how much of the keyboard macro is actually minibuffer
input, not compile that portion, and arrange for it to be read as
minibuffer input by the command.  It could probably figure this out if
the input were arguments processed by the 'interactive' declaration,
but if the function just does minibuffer input on its own it has
little chance.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar