unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: schwab@suse.de, emacs-devel@gnu.org
Subject: Re: query-replace-regexp-eval is quite nice, but...
Date: 02 Feb 2004 13:17:25 +0100	[thread overview]
Message-ID: <x5llnln0a2.fsf@lola.goethe.zz> (raw)
In-Reply-To: <200402021216.i12CGdKb015329@beta.mvs.co.il>

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Mon, 02 Feb 2004 11:24:34 +0100, Andreas Schwab <schwab@suse.de> wrote:
> >
> > David Kastrup <dak@gnu.org> writes:
> >
> > [snip]
> > >
> > > So the idea is to build your replacement string with Lisp, and this
> > > is quite an excellent thing.  It is completely defeated because the
> > > replacement is then done non-literally.  Which means that if \0
> > > would have matched \footnote, replacing the string just with \0 (which
> > > one would expect to do nothing in effect) will barf because the
> > > regexp replacer will not know what \f is supposed to be.
> >
> > I agree this is a bug.
> >
> > > Is there anybody that would make a case for a non-literal
> > > replacement?  If not, is there anybody with enough of a clue to find
> > > out how to fix this?  I have taken a look at perform-replace, but it
> > > does not seem to offer an option for literal replacement for
> > > regexps.  Should we add one?
> >
> > Currently, perform-replace uses literal replacement for all non-regexp
> > searches, and non-literal otherwise.  What we could do is offer a special
> > version of match-string that quotes backslashes and use that in
> > replace-match-string-symbols.
> 
> How about checking regexp-flag (which is bound by `perform-replace') ?
> 
> Assuming your "literal" result string (containing \n) is STR you can
> add something like this to your lisp:
> 
>        (if regexp-flag
>            (regexp-quote STR)
>            STR)

"add something like this to my lisp"?  query-replace-regexp-eval is
an interactive function!  Even if it weren't, there is no point in
having two substitution mechanisms employed after another.

I have cobbled together the following minimal-invasive patch.  The
new argument-option of regexp-eval is not documented but obvious.
Since no other args are documented, either, with perform-replace,
this does not seem to do much harm and it won't affect existing use
of it.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1563 bytes --]

*** replace.el.~1.166.~	2003-09-08 17:57:00.000000000 +0200
--- replace.el	2004-02-02 13:07:58.000000000 +0100
***************
*** 223,229 ****
  	   (if (and transient-mark-mode mark-active)
  	       (region-end)))))
    (perform-replace regexp (cons 'replace-eval-replacement to-expr)
! 		   t t delimited nil nil start end))
  
  (defun map-query-replace-regexp (regexp to-strings &optional n start end)
    "Replace some matches for REGEXP with various strings, in rotation.
--- 223,229 ----
  	   (if (and transient-mark-mode mark-active)
  	       (region-end)))))
    (perform-replace regexp (cons 'replace-eval-replacement to-expr)
! 		   t 'literal delimited nil nil start end))
  
  (defun map-query-replace-regexp (regexp to-strings &optional n start end)
    "Replace some matches for REGEXP with various strings, in rotation.
***************
*** 1057,1063 ****
  	(case-fold-search (and case-fold-search
  			       (string-equal from-string
  					     (downcase from-string))))
! 	(literal (not regexp-flag))
  	(search-function (if regexp-flag 're-search-forward 'search-forward))
  	(search-string from-string)
  	(real-match-data nil)		; the match data for the current match
--- 1057,1063 ----
  	(case-fold-search (and case-fold-search
  			       (string-equal from-string
  					     (downcase from-string))))
! 	(literal (or (not regexp-flag) (eq regexp-flag 'literal)))
  	(search-function (if regexp-flag 're-search-forward 'search-forward))
  	(search-string from-string)
  	(real-match-data nil)		; the match data for the current match

[-- Attachment #3: Type: text/plain, Size: 410 bytes --]


Since the current behavior is clearly wrong, the fix does not cause
any incompatibilities elsewhere, and the semantics are the obvious
ones as already documented, I'll just check it in.

If one wants to force more complicated things onto people, one can
still change stuff (including the documentation), but for the current
docs this behavior seems correct.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

  reply	other threads:[~2004-02-02 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-02  8:53 query-replace-regexp-eval is quite nice, but David Kastrup
2004-02-02 10:24 ` Andreas Schwab
2004-02-02 11:19   ` David Kastrup
2004-02-02 12:16   ` Ehud Karni
2004-02-02 12:17     ` David Kastrup [this message]
2004-02-02 13:10       ` Andreas Schwab
2004-02-02 15:01         ` David Kastrup
2004-02-02 15:52         ` Stefan Monnier
2004-02-03 13:22           ` Andreas Schwab
2004-02-02 13:03     ` Andreas Schwab
2004-02-02 15:03       ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x5llnln0a2.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).