From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: query-replace-interactive Date: Mon, 05 Jul 2004 09:08:46 +0300 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87k6xjouj5.fsf@mail.jurta.org> References: <876594drn6.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 1089008226 23075 80.91.224.253 (5 Jul 2004 06:17:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jul 2004 06:17:06 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jul 05 08:16:58 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 1BhMmg-0008Iq-00 for ; Mon, 05 Jul 2004 08:16:58 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BhMmf-0004Yb-00 for ; Mon, 05 Jul 2004 08:16:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhMoc-0001GR-OY for emacs-devel@quimby.gnus.org; Mon, 05 Jul 2004 02:18:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BhMoZ-0001GE-UL for emacs-devel@gnu.org; Mon, 05 Jul 2004 02:18:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BhMoZ-0001Fv-3z for emacs-devel@gnu.org; Mon, 05 Jul 2004 02:18:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhMoZ-0001Fs-1a for emacs-devel@gnu.org; Mon, 05 Jul 2004 02:18:55 -0400 Original-Received: from [66.33.219.6] (helo=knife.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BhMm8-0005x5-2P for emacs-devel@gnu.org; Mon, 05 Jul 2004 02:16:24 -0400 Original-Received: from mail.jurta.org (80-235-32-32-dsl.mus.estpak.ee [80.235.32.32]) by knife.dreamhost.com (Postfix) with ESMTP id 7057FE4037; Sun, 4 Jul 2004 23:16:21 -0700 (PDT) Original-To: Stefan In-Reply-To: (Stefan's message of "04 Jul 2004 12:13:36 -0400") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) 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:25450 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25450 Stefan writes: >> But the last search string still could be used as the `default' >> argument of `read-from-minibuffer'. This is not quite a "default" >> value but rather what the Emacs manual names as "future history" value, >> i.e. the value available with M-n. > > I think we've already agreed that M-% should offer > > Query replace (default foo -> bar): > > i.e. default to redo the same replace as last time, rather than use the > last search string. Even if using the last replacement as default doesn't hurt, such use of the default value is non-standard in Emacs. Usually, the default value is available for inserting into the minibuffer by typing M-n, but not in this case, since inserting "foo -> bar" into the minibuffer is useless. Moreover, the last replacement actually consists of the last elements of the replacement history. The standard Emacs way to access the history values is M-p. But this is not possible for two separate replacement values (from and to) either. One possibility to follow Emacs conventions is to use a user-defined value `query-replace-args-separator' to allow to specify both from-string and to-string in the same input string. In this case there is no need in interpreting an empty input string as repeating the last replacement since the last replacement (as well as all previous replacements) are easily accessible by M-p. However, I am not sure this option should have some non-nil value by default. 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'. >> I implemented it having in mind users' requests for the ability to >> copy words from the buffer into the from-string. Now this is possible >> by typing: > >> 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. 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 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. >>> (perform-replace isearch-string nil t isearch-regexp isearch-word) instead. >> === >> If the argument `replacements' is nil, this function signals an error. >> Moreover, it's impossible to guess the to-string, so asking for it from >> the user is still inevitable. > > Oh, right, I forgot that part of my local hacks > [...] > 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'. > 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. -- Juri Linkov http://www.jurta.org/emacs/