From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: On converting from kbd macro to elisp code Date: Wed, 4 Oct 2006 09:37:17 -0700 (PDT) Message-ID: <33020.128.165.123.18.1159979837.squirrel@webmail.lanl.gov> References: Reply-To: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1159980058 8203 80.91.229.2 (4 Oct 2006 16:40:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2006 16:40:58 +0000 (UTC) Cc: Herbert Euler , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 04 18:40:54 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GV9kX-0000oR-9u for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2006 18:37:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GV9kW-0004OC-Qq for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2006 12:37:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GV9kK-0004MG-TH for emacs-devel@gnu.org; Wed, 04 Oct 2006 12:37:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GV9kI-0004HO-P4 for emacs-devel@gnu.org; Wed, 04 Oct 2006 12:37:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GV9kI-0004H6-Jx for emacs-devel@gnu.org; Wed, 04 Oct 2006 12:37:22 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GV9qk-0003Y5-DV; Wed, 04 Oct 2006 12:44:02 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k94GbIps024667; Wed, 4 Oct 2006 10:37:18 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k94GbHLw003466; Wed, 4 Oct 2006 10:37:17 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id k94GbH4Y004357; Wed, 4 Oct 2006 10:37:17 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k94GbH7A004355; Wed, 4 Oct 2006 09:37:17 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Wed, 4 Oct 2006 09:37:17 -0700 (PDT) In-Reply-To: Original-To: "Richard Stallman" User-Agent: SquirrelMail/1.4.6-7.el3.7lanl X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 X-MIME-Autoconverted: from 8bit to quoted-printable by mailwasher-b.lanl.gov id k94GbIps024667 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:60415 Archived-At: > 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?=20 (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=EFve 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 Lis= p translation could be made via that hook. However, minibuffer arguments would still pose quite a problem; perhaps i= t 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 --=20 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.