From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: query-replace-interactive not documented Date: 16 Jun 2004 13:30:40 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040528.181649.25475113.wl@gnu.org> <200405291737.i4THbPJ06689@raven.dms.auburn.edu> <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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087385445 26275 80.91.224.253 (16 Jun 2004 11:30:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2004 11:30:45 +0000 (UTC) Cc: Juri Linkov , schwab@suse.de, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 16 13:30:37 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 1BaYcn-0007Iv-00 for ; Wed, 16 Jun 2004 13:30:37 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaYcn-00019D-00 for ; Wed, 16 Jun 2004 13:30:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaYdm-0001nV-N0 for emacs-devel@quimby.gnus.org; Wed, 16 Jun 2004 07:31:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BaYdk-0001nQ-2s for emacs-devel@gnu.org; Wed, 16 Jun 2004 07:31:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BaYdh-0001nE-Pl for emacs-devel@gnu.org; Wed, 16 Jun 2004 07:31:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaYdh-0001nB-Kz for emacs-devel@gnu.org; Wed, 16 Jun 2004 07:31:33 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1BaYca-0008LW-Uk for emacs-devel@gnu.org; Wed, 16 Jun 2004 07:30:25 -0400 Original-Received: (qmail 80388 invoked from network); 16 Jun 2004 11:30:23 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 16 Jun 2004 11:30:23 -0000 Original-To: David Kastrup In-Reply-To: Original-Lines: 55 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:25031 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25031 David Kastrup writes: > Juri Linkov writes: > > > storm@cua.dk (Kim F. Storm) writes: > > > Andreas Schwab writes: > > >> Juri Linkov writes: > > >> > To use a single variable inside a replacement string, one can use > > >> > a no-op function like `+': > > >> > > >> Or even progn. > > > > > > Or or, which is even shorter... > > > > Which is shorter only for non-numeric variables. > > But for numeric variables + is the shortest one. > > > > But there is still one too long name that the user should type: > > `replace-count'. WIBN to have aliases for this name? > > At least, `c' and `i' would make sense. > > > > So, instead of: > > > > C-M-% \\footnote{ RET \&\\label{fn:\,(+ replace-count)} RET > > > > to type: > > > > C-M-% \\footnote{ RET \&\\label{fn:\,(+ c)} RET > > I'd rather say that since we already have special symbols > \1 \2 \3 \#1 \#2 \#3, that the most natural choice would probably be > just \# for the match number. Then we'd have > > \\label{fn:\,\# } RET > > And it would probably make sense to define \# as a string component > on its own, too, so that we can just write > \\label{fn:\#} RET > if we want to. > \, and \# both looks good to me. The extra space after the \, form should be optional, i.e. if there is a space, remove it, if not, it's not an error. I haven't studied the two proposed implementations in details, but if there is an issue re. security and non-interactive calls, it might make sense to simply not accept these formats if called non-interactively. After all, this function is called QUERY-replace-regexp. -- Kim F. Storm http://www.cua.dk