From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: isearch-query-replace-regexp and stuff Date: 02 Jul 2004 09:55:49 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87d63ec1py.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 1088754992 24783 80.91.224.253 (2 Jul 2004 07:56:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2004 07:56:32 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jul 02 09:56:25 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 1BgIuH-0006Tv-00 for ; Fri, 02 Jul 2004 09:56:25 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BgIuG-0001Nz-00 for ; Fri, 02 Jul 2004 09:56:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgIw2-0004z6-Jy for emacs-devel@quimby.gnus.org; Fri, 02 Jul 2004 03:58:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BgIvx-0004yD-L6 for emacs-devel@gnu.org; Fri, 02 Jul 2004 03:58:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BgIvv-0004xF-Bk for emacs-devel@gnu.org; Fri, 02 Jul 2004 03:58:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BgIvv-0004x9-3Z for emacs-devel@gnu.org; Fri, 02 Jul 2004 03:58:07 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BgItp-0007n4-Gr for emacs-devel@gnu.org; Fri, 02 Jul 2004 03:55:57 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BgItn-00057F-4B; Fri, 02 Jul 2004 03:55:57 -0400 Original-To: Juri Linkov In-Reply-To: <87d63ec1py.fsf@mail.jurta.org> Original-Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:25377 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25377 Juri Linkov writes: > David Kastrup writes: > > As far as I am able to judge from the current code that is just > > checked in, if one types M-% from within a regexp isearch or C-M-% > > from within an ordinary isearch, the history variable of the last > > irrelevant search type gets consulted. That seems weird. > > That might seem weird, but it allows users to do weird things if they > want so. Users may want to search with C-s for a regexp in the > buffer and start C-M-% with a regexp copied literally from the search > string. This is not what I guessed from the code, but I might be mistaken. But I don't consider it likely. And the same reasoning would hold that users might want to search with C-u C-s for a regexp and start C-M-% with regexp copied literally from the search string. If you want to start over with something you found, then start over. It does not make sense to define some secret switch-horses functionality here. The other thing that might make sense is to just define M-% and use it to start regexp replacements in regexp searches, and non-regexp replaced in normal isearch. It might be confusing. OTOH, the C-s binding during searches already has this sort of split personality. > > I think that M-% from within a regexp isearch should probably use > > the currently matched string, and C-M-% from within an ordinary > > isearch should probably use regexp-quote of the current search > > string. > > > > I have no brilliant idea of what to do if we type M-% in a regexp > > isearch and there is no currently matched string. Probably just beep > > and refuse, which would also be the sanest option if the regexp is > > currently incomplete. Of course, if query-replace-interactive is > > 'initial, one might possibly just provide an empty string as initial > > value (leaving the history in peace), and if it is nil, we need not > > bother anyhow. > > All this makes sense. We could implement this for the sake of user > convenience provided that this is what most users would expect, but > often mandatory conveniences are too annoying. Well, the existing behavior does not seem particularly useful, and far from obvious. My proposal has the purpose of keeping a successful search successful. > > While we are at it: maybe M-s should turn an ordinary search into > > a regexp search (while regexp-quoting the current search string to > > make it fitting for a regexp search), and vice versa (by using the > > currently matched string, if any, as search string). > > Do you propose a new key binding M-s or do you actually mean > modifying the existing M-r? M-r currently toggles regular-expression > mode, but it neither quotes the regexp nor turns the search regexp > into the matched string. Oops, didn't realize that. > We could use a prefix argument of M-r to implement these things > instead of adding a new key binding. No, we couldn't. Prefix arguments exit the search. It might make sense when switching to use the respective search history's last entry _if_ it happens to match at point. That way, M-r M-r would be a noop instead of turning a general regexp into one just matching a string. OTOH, there is little motivation for typing M-r M-r anyhow. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum