From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Is there a plan to record kbd macro as elisp code? Date: Sun, 28 Oct 2007 09:50:41 -0400 Message-ID: References: <87wst8uub5.fsf@kfs-lx.testafd.dk> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1193579877 7498 80.91.229.12 (28 Oct 2007 13:57:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2007 13:57:57 +0000 (UTC) Cc: yezonghui@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 28 14:57:59 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Im8eL-0007Ao-R1 for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 14:57:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Im8eC-00023E-OE for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 09:57:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Im8XP-0005XW-M8 for emacs-devel@gnu.org; Sun, 28 Oct 2007 09:50:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Im8XN-0005W9-FW for emacs-devel@gnu.org; Sun, 28 Oct 2007 09:50:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Im8XM-0005Vd-Nw for emacs-devel@gnu.org; Sun, 28 Oct 2007 09:50:45 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Im8XK-0008Cz-Tt for emacs-devel@gnu.org; Sun, 28 Oct 2007 09:50:43 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Im8XJ-0000uK-CL; Sun, 28 Oct 2007 09:50:41 -0400 In-reply-to: <87wst8uub5.fsf@kfs-lx.testafd.dk> (storm@cua.dk) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:81945 Archived-At: Which reminds me that there is a big difference between replaying a keyboard macro and running the corresponding functions as a single command: - the pre-command-hook and post-command-hook are run for each key in the keyboard macro, but only once for the single command. This doesn't mean that the elisp code cannot be equivalent to the keyboard macro, but it may be much harder to do right. There are various ideas of what is "right" for such a conversion. I think the converted code should ignore these hooks, and if the results are different, in most cases that will make sense. Delete Selection mode is an exception. In Delete Selection mode, if these hooks are not run, the results will clearly be wrong. The same may be true of CUA mode. The conversion program could test for the presence of these specific hook functions in pre-command-hook, and generate appropriate code in the output Lisp function. Rather than calling these hook functions before each command, it should call them only in the places where they would do real work. And it wouldn't call the same function, but rather a related one. Here's what it could look like: (put 'delete-selection-pre-hook 'lisp-conversion-function (lambda (function) (let ((type (and (symbolp this-command) (get this-command 'delete-selection)))) (when type `(delete-selection-pre-command-processing ,type))))) where `delete-selection-pre-command-processing' would be a new function that does the same work as `delete-selection-pre-hook' but gets `type' as an argument.