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: recording-elisp.el - try recording commands as elisp code Date: Mon, 05 Nov 2007 01:20:04 -0500 Message-ID: References: <87k5p05qsy.fsf@jurta.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1194243620 15403 80.91.229.12 (5 Nov 2007 06:20:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2007 06:20:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: yzhh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 05 07:20:23 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 1IovJs-0003NW-PD for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 07:20:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IovJi-0006Pl-2V for ged-emacs-devel@m.gmane.org; Mon, 05 Nov 2007 01:20:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IovJf-0006PT-Df for emacs-devel@gnu.org; Mon, 05 Nov 2007 01:20:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IovJd-0006P6-U3 for emacs-devel@gnu.org; Mon, 05 Nov 2007 01:20:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IovJd-0006Oh-Nl for emacs-devel@gnu.org; Mon, 05 Nov 2007 01:20:05 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IovJd-0004XS-CB for emacs-devel@gnu.org; Mon, 05 Nov 2007 01:20:05 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IovJc-00052V-Sf; Mon, 05 Nov 2007 01:20:04 -0500 In-reply-to: (message from yzhh on Sun, 04 Nov 2007 16:51:49 +0800) 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:82544 Archived-At: However, two things I mentioned above are difficult to do right: 1. "recognize whether a string is killed during the recording". There are quite a few sources for yanking, including the whole kill-ring. Tracking them all is asking for trouble. You're being too perfectionist. Please stop asking whether you can "track them all", and instead work on tracking common cases. I am sure you will succeed. The only question is how far you can carry it. rms's approach want: (isearch-forward) (isearch-append-string "abc") (isearch-yank-kill) (isearch-repeat-forward) (isearch-exit) Well, isearch-append-string is imagined, the most close thing we have is isearch-printing-char (WITH NO ARGS). AFAIK, this and other "lack-of-support" reason rendered rms's approach impossible for now. We can add isearch-append-string for this. > Likewise, if a macro does a search with C-s C-s (using the default > from before the macro), it is far better to generate a program that > will use the default, rather than one which uses a constant. That might be "kbd macro" thinking. For recorded lisp code, it's better to modify it to receive an arg "interactively", than to receive it from previous prepared "runtime environment" (in this case, the latest search string). That is a good idea. Please do it that way. The same argument would apply to yanking something that was not killed within the same macro. We may provide an option "recording minibuffer editing on/off", or even provide commands to switch it during the recording. But the real challenge is not recording but replaying. Example: M-x previ TAB line RET The recorded commands: (execute-extended-command nil) (insert "previ") (minibuffer-complete) (insert "line") (previous-line 1 1) can not be replayed directly, because running the first command will prompt the user for input instead of continue running. The code to set up an argument in the minibuffer needs to be converted into computing the argument to pass to a function. However, mere completion in most cases can be treated as a constant. Thus, if the user types M-x que SPC SPC SPC RET, there is no need for your code to go through the routine of completing `que'. You should just generate a call to `query-replace-region'. The only possible exceptions to that statement are cases where the effect of the completion is very dynamic. I don't know whether any such cases exist; I mention the possibility because I am not yet convinced there are none. Thus, the issue that complicates minibuffer args is not completion. It is yanking.