* Re: On converting from kbd macro to elisp code
2006-09-08 11:56 ` Richard Stallman
@ 2006-10-04 16:37 ` Stuart D. Herring
0 siblings, 0 replies; 4+ messages in thread
From: Stuart D. Herring @ 2006-10-04 16:37 UTC (permalink / raw)
Cc: Herbert Euler, emacs-devel
> 2. Even if keybindings are not changed, the same keyboard macro may
> mean different operations for different major modes and/or minor
> modes. Does each mode need a conversion?
>
> Again, it should operate based on the current bindings.
> The point is to produce nice-looking Lisp code
> that could be a good start for hand-editing.
I've been considering working on this. It has occurred to me that there
are several other uncertainties:
- If the macro switches buffers/modes, even the bindings current at the
time of invocation may not be the only ones relevant. It seems
particularly useless to not parse [ ?\M-x ?c ?+ ?+ ?\C-m ?\C-c ?\C-q ] to
(progn (c++-mode) (c-indent-defun)); similarly [ ?\C-x ?d ... ] should
obviously do something with Dired's commands.
- Many functions behave differently if called interactively (e.g.,
printing messages that may be the point of the macro). Do we want to use
`call-interactively' to try to mimic the actual results of the macro?
(Of course, for things that prompt for arguments, `call-interactively' is
the wrong answer. Some commands could have their INTERACTIVE arguments
passed...).
- If a macro does completion in the minibuffer or so, is the generated
Lisp supposed to include what such completion might produce if attempted
at the time when (and in the possibly-entirely-unrelated environment in
which) the Lisp is generated? Of course, the macro does the completion
at run time; should the Lisp then delay its attempt at completion until
it is run?
- Similarly, a macro may use default arguments (e.g., from history
lists). Should the generated Lisp use (at translation time) what they
would be if the macro were run then, or discover what the defaults are at
run time?
- This is getting somewhat abstruse, but what about macros that invoke
the minibuffer but then switch out of it and continue editing? Is that
supposed to generate
;; At this point the macro started to invoke `find-file'.
(let ((defaults-for-next-command ...)) (other-buffer) ...
;; Now the macro finally commits its arguments:
(find-file (nth ... defaults-for-next-command)))
? Obviously, with recursive minibuffers things could get worse.
- There is in general no way to discover what calls to `completing-read'
and such that a command (discovered via a key sequence in the macro that
may or may not precede arguments) might make without actually executing
it. Even `interactive' specs that are in fact lists are automatically
unanalyzable; I note that such basic things as `load-file' and
`revert-buffer' have those.
The net result, as far as I can tell, is that all but the most naïve
interpretations of keyboard macros must be done by watching them execute
rather than via static analysis. I see that `this-command' is set even
when `pre-command-hook' is being run, so I suppose a very rudimentary Lisp
translation could be made via that hook.
However, minibuffer arguments would still pose quite a problem; perhaps it
would be best if there was some sort of (optionally-run) tracing code in
`execute-kbd-macro' (or rather, in command_loop_1()) itself. Perhaps the
command-handling code could make a series of simple calls to a Lisp
logging interface ("minibuffer entered", "command run: blah") that could
later assemble it into sensible Lisp. Or it might make sense to use
`call-interactively', since it already generates `command-history'.
Thoughts? Suggestions?
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.
^ permalink raw reply [flat|nested] 4+ messages in thread