From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: yzhh Newsgroups: gmane.emacs.devel Subject: Re: recording-elisp.el - try recording commands as elisp code Date: Sun, 04 Nov 2007 16:51:49 +0800 Message-ID: References: <87k5p05qsy.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1194166397 17923 80.91.229.12 (4 Nov 2007 08:53:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Nov 2007 08:53:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 04 09:53:20 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 1IobEM-00086V-Hk for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2007 09:53:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IobEB-0005mq-Ra for ged-emacs-devel@m.gmane.org; Sun, 04 Nov 2007 03:53:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IobDU-0005NZ-81 for emacs-devel@gnu.org; Sun, 04 Nov 2007 03:52:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IobDT-0005NB-OV for emacs-devel@gnu.org; Sun, 04 Nov 2007 03:52:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IobDT-0005N4-Cf for emacs-devel@gnu.org; Sun, 04 Nov 2007 03:52:23 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IobDS-000824-KC for emacs-devel@gnu.org; Sun, 04 Nov 2007 03:52:23 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IobDI-0002OL-J7 for emacs-devel@gnu.org; Sun, 04 Nov 2007 08:52:12 +0000 Original-Received: from 211.90.238.185 ([211.90.238.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2007 08:52:12 +0000 Original-Received: from yezonghui by 211.90.238.185 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Nov 2007 08:52:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 107 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 211.90.238.185 User-Agent: KNode/0.10.5 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:82488 Archived-At: Richard Stallman wrote: > It was suggested: > > > I think it is enough to convert the isearch exit event with the > > last search string to the calls of search-forward, search-backward, > > re-search-forward and re-search-backward. > > That is a good approach for the simple cases. But if the user yanks > into the search, it is important to at least try to reproduce the > effect of the yanking. Even if it can't work right in all cases, at > least it should work right in simple cases. In the case of iserach. I think it might be a good approach to output a constant string search when the yanked string is not killed during the recording, and to output a yank-in-the-search when the killing is also recorded. 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. 2. "output a yank-in-the-search". That is actually to require reproducing the whole isearch session, since the yanking can happen anytime during isearch, and can be surrounded by other search string editing. That's really really difficult - the required information is NOT ALL available from recorded isearch commands and the isearch state stack. My current implementation does neither. To illustrate, let's see what we get for this isearch session (3 searches are all successful): C-s abc M-y(yank "def" from kill-ring) C-s RET Juri's approach get: (search-forward "abcdef") My implementation get: (search-forward "abc") (search-forward "abcdef" (search-forward "abcdef") 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. What do we really want here? > 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). If you're talking about kill-and-yank during the recording, that's reasonable. Then my analysis above and bellow apply. > The same goes for minibuffers. When someone uses completion in a > minibuffer, there are many cases where using the end result as a > constant is best, and perhaps that is always good; but there could be > some cases where it is important to repeat the completion operation. > (I am not sure.) And yanking into the minibuffer ought to be repeated. 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. This is a foundmental difference between kbd macro and lisp code. And I don't known how to do "call-interactively without promting the user" from code. Another issue is with recognizing (previous-line ...) as "to be deleted" to avoid doing it twice. We'll have to put some flag on this recorded command at recording time, and this flag depends on a previous (execute-extendied-command nil) plus 'leaving minibuffer' event. > As regards isearch-case-fold-search, I think it is ok to ignore that. > The generated code should simply call a search function, which will > obey case-fold-search. I think this will produce the most useful Lisp > code, in terms of practical use. If one toggles case-fold during isearch, I believe he does it for a reason and we'd better record it. Currently the generated code looks like this: (defun recorded-command () (interactive) (let ((case-fold case-fold-search)) ; save case-fold (setq case-fold-search t) ; set to recorded value ... (search-forward "something") (setq case-fold-search (not case-fold-search)) ; user toggles case-fold (search-forward "SOMETHING") ; last isearch string (setq case-fold-search (not case-fold-search)) ; toggle it back ... (setq case-fold-search case-fold))) ; restore case-fold It easy to do without the "case-fold" lines, though. Or another option can be used to turn this on/off. -- regards, yzhh