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: query-replace-interactive not documented Date: 19 Jun 2004 09:00:22 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040528.181649.25475113.wl@gnu.org> <873c5jug73.fsf@mail.jurta.org> <87oenqa4lu.fsf@mail.jurta.org> <873c51w5rq.fsf@mail.jurta.org> <87659snbd8.fsf@mail.jurta.org> <87llin98sc.fsf@mail.jurta.org> <87hdtbtnsg.fsf@mail.jurta.org> <87brjhwe2c.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 1087628452 9668 80.91.224.253 (19 Jun 2004 07:00:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 19 Jun 2004 07:00:52 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Jun 19 09:00:46 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 1BbZqI-0006fC-00 for ; Sat, 19 Jun 2004 09:00:46 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BbZqH-0006oS-00 for ; Sat, 19 Jun 2004 09:00:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BbZrQ-0002MI-67 for emacs-devel@quimby.gnus.org; Sat, 19 Jun 2004 03:01:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BbZrN-0002MB-PB for emacs-devel@gnu.org; Sat, 19 Jun 2004 03:01:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BbZrM-0002Lz-BQ for emacs-devel@gnu.org; Sat, 19 Jun 2004 03:01:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BbZrM-0002Lw-9o for emacs-devel@gnu.org; Sat, 19 Jun 2004 03:01:52 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BbZq3-0007kh-88 for emacs-devel@gnu.org; Sat, 19 Jun 2004 03:00:31 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BbZpw-0001g5-1u; Sat, 19 Jun 2004 03:00:24 -0400 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 49 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:25106 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25106 Richard Stallman writes: > > Using a space to end a variable name after `\,' is a clean solution. > > Using a space is fine, but not deleting it. > > Yes, it should delete the space. Users will find this natural once > they know about it. Many other programs have had such interfaces. Wel, optional spaces in the middle of regexp are something that needs extra explaining. And the question is how to make that rule consistent. There are some Lisp expressions that are "self-sufficient", like everything enclosed in parens or quotes, and some that are ended by an incompatible character following, like symbols. Actually, I can't think about much except symbols here, and maybe forms like 'symbol which end up as a list. It does feel somewhat strange that the replacement expression x + \,(1+ \#) + y; would swallow a space, and even requiring something like x + \,replace-count + y; is not particularly pretty. > Instead of deleting the space, in cases where the user DON'T want a > space between a variable value and the followed text, he can add > separators like the close paren in "\,(or variable)text". > > That is much less convenient. Somewhat (4 more letters), but it is also rarely needed. The only _variable_ identifier that is really defined in replacements is replace-count, and I added the shorthand \# for what would amount to \'replace-count already. So we are basically just talking about constants stored in Lisp symbols, and there is not much of an incentive for using those: you can just write the contents in the replacement string instead. So I think we are talking about an additional rule that would be required rather rarely in practice, has an easily available workaround available, and that would either need to have special exceptions again or would also impact expressions that are already properly bracketed and don't need additional spaces, by far the most common occurence. Have you taken a look at the DOC-string of the currently checked-in version of query-replace-regexp? I think the current behavior is, all in all, clear, convenient and easily explained. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum