GNU bug report logs - #35354
26.2; `dired-do-query-replace-regexp': How to replace only word-delimited matches?

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 21 Apr 2019 03:35:02 UTC

Severity: minor

Found in version 26.2

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: npostavs <at> gmail.com
Cc: 35354 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#35354: 26.2; `dired-do-query-replace-regexp': How to replace only word-delimited matches?
Date: Mon, 29 Apr 2019 19:29:00 -0700 (PDT)
> >>>>> "Drew" == Drew Adams <drew.adams <at> oracle.com> writes:
> >>>>> "Dmitry" == Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>     Drew> I was expecting that it would do all that the latter does plus
>     Drew> more.
> 
>     Dmitry> I don't really understand how we can both expect FROM to be a
>     Dmitry> regexp and have a separate argument DELIMITED.
> 
>     Drew> Why is that a problem?
> 
> It seems to give some possibly unexpected results.  For example, with
> this buffer contents:
> 
>     word fooooo bar word
>     word foo bar word
> 
> C-u C-M-% foo.*bar RET replaces only the "foo bar" on the second line,
> not the "fooooo bar" on the first line.  That is to say, it's unclear
> (to me at least) what DELIMITED means for regexps which can match both
> word and non-word characters.

The doc says that only the start and end of the match
need be word boundaries.  So I guess that Dmitry is
right that in the case where the input is interpreted
as a regexp non-nil DELIMITED can only be a convenience
for not having to use \v.

I was thinking that DELIMITED acted as a second filter,
requiring not only word boundaries at beginning and end
but also that all chars matched be word-constituent.
That's clearly not the case though, and the doc doesn't
suggest it should be.

Your example points out a regression.  It was introduced
in Emacs 24.5.  In Emacs 20-23 (and probably pre-20) it
acts correctly (per the doc): both lines of your example
are treated the same: fooooo bar is matched.  Starting
with Emacs 24.5 the doc is no longer respected.

Was the change intentional, and someone forgot to update
the doc?  I doubt it.  This change/regression coincides
with the introduction of `replace-search' and
`replace-highlight' and the use of `isearch-word', which
later became ` isearch-regexp-function'.  Before that,
`perform-replace' just did this:

    (if delimited-flag
	(setq search-function 're-search-forward
	      search-string (concat "\\b"
				    (if regexp-flag from-string
				      (regexp-quote from-string))
				    "\\b")))

> I understand how the match can be delimited, but I don't understand how
> the replacement can be delimited.

Right.  I was wrongly thinking that non-nil DELIMITED
meant that the otherwise-matches were in addition
filtered by also requiring their chars to be word
constituents.

>     Dmitry> Is there a practical difference between this and
>     Dmitry> using a regexp with word boundaries as FROM?
> 
>     Drew> See `query-replace-regexp'.  Why do you think it has argument
>     Drew> DELIMITED?
> 
> I think it might be just to save the user from typing `\<' and `\>'.
> Did you have another reason in mind?  If so, please say it plainly,
> thanks.

I think you must be right.  Clearly for the `query-replace'
case it is useful as such.  For the `query-replace-regexp'
case it is not as useful.

But even in that case it can be useful in this sense:
You can _reuse_ a regexp in a different search, and just
use a prefix arg to temporarily restrict the matches to
having word boundaries - no need to edit the regexp.
Not a big win, granted, but if you need to go back and
forth then it could be a convenience.

The point of this bug report is that if we replace the
command used by `Q' with another then we should maybe
have it do at least as much.

DELIMITED has been in Emacs for the functions that use
it (in replace.el) for a very long time.




This bug report was last modified 3 years and 118 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.