From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: query-replace-interactive Date: 05 Jul 2004 08:44:43 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <876594drn6.fsf@mail.jurta.org> <87k6xjouj5.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1089031520 8758 80.91.224.253 (5 Jul 2004 12:45:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jul 2004 12:45:20 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jul 05 14:45:10 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BhSqL-0002rK-00 for ; Mon, 05 Jul 2004 14:45:09 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BhSqK-0002d7-00 for ; Mon, 05 Jul 2004 14:45:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhSsI-00072A-GB for emacs-devel@quimby.gnus.org; Mon, 05 Jul 2004 08:47:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BhSs8-0006zb-BU for emacs-devel@gnu.org; Mon, 05 Jul 2004 08:47:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BhSs6-0006yn-I9 for emacs-devel@gnu.org; Mon, 05 Jul 2004 08:46:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhSs6-0006yb-EX for emacs-devel@gnu.org; Mon, 05 Jul 2004 08:46:58 -0400 Original-Received: from [206.47.199.166] (helo=simmts8-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BhSpy-0004wI-7n for emacs-devel@gnu.org; Mon, 05 Jul 2004 08:44:46 -0400 Original-Received: from empanada.local ([67.71.25.81]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040705124412.QVLY28685.simmts8-srv.bellnexxia.net@empanada.local>; Mon, 5 Jul 2004 08:44:12 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id 0F8FD24240A; Mon, 5 Jul 2004 08:44:43 -0400 (EDT) Original-To: Juri Linkov In-Reply-To: <87k6xjouj5.fsf@mail.jurta.org> Original-Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25453 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25453 > But even in case with the default to repeat the last replacement it is > possible to use the last search string/regexp as a default value only > for the sake of making it available by M-n. But the real default value > (such as used when the user types RET with empty input) could be > interpreted as repeating the last replacement, since if the user > enters empty input, `read-from-minibuffer' returns the empty string, > not the argument `default-value'. But as you said regarding the "a -> b" default, "such use of the default value is non-standard in Emacs". And more importantly, it's unimportant. If you want to reuse a previous search string for replacement, just do C-s C-s M-% instead of M-% M-n RET this also has the advantage of being more general, so you can also do a replacement on the penultimate search string if you want: C-s M-p M-p C-s M-% >>> C-s C-w C-w ... M-% >> >> C-SPC M-f M-f ... M-w M-% C-y > Yes, currently this is the most convenient method to do that but it > requires more keystrokes and wastes the kill ring. For what it's worth, I can also do M-% C-w C-w C-w RET since I've added a C-w binding in minibuffer-local-map that mimics isearch's C-w. > There are other cases where making the last search string accessible > by M-n is useful. For example, users might want to start replacing > the current search string from the beginning of the buffer. To not > type C-r several times to reach the beginning of the buffer the user > can type: > C-s C-w C-w ... RET M-< M-% M-n RET Why is that better than C-s C-w C-w ... RET M-< C-s M-% > So, in conclusion, I agree that M-% in isearch should not ask for > the from-string with initial content of the last search string, > but M-% invoked not from isearch could provide the last search string > by M-n. I don't think it's worth the trouble. >> Obviously, it's not good enough. But we can easily take out the "read >> `to'" part of query-replace-read-args. > Calling `perform-replace' directly is not good because it skips many > useful things implemented in interactive commands which call it. > Most useful of them is recently added handling of \, and \# in > `query-replace-read-args'. That's exactly what I meant by the "read `to'" part. We can take it out of query-replace-read-args and call it explicitly. >> The point about using perform-replace is that it allows us to obey >> both isearch-regexp and isearch-word without doing any if-gymnastic. > Using `isearch-regexp' to call either `query-replace' or > `query-replace-regexp' is easy. Using the value of `isearch-word' for > replacement might be tricky but currently this is possible with the > prefix argument C-u M-% or C-u C-M-% even in isearch. And if you call perform-replace it's neither tricky nor requires remembering any particular C-u combination. Stefan