From: Drew Adams <drew.adams@oracle.com>
To: npostavs@gmail.com
Cc: 35354@debbugs.gnu.org, Dmitry Gutov <dgutov@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) [thread overview]
Message-ID: <ba5742e5-410e-467f-9d17-d3fc690827e8@default> (raw)
In-Reply-To: <08ee0770-3f50-433e-955e-f8e13547ec21@default>
> >>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:
> >>>>> "Dmitry" == Dmitry Gutov <dgutov@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.
prev parent reply other threads:[~2019-04-30 2:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 3:20 bug#35354: 26.2; `dired-do-query-replace-regexp': How to replace only word-delimited matches? Drew Adams
2019-04-21 23:08 ` Dmitry Gutov
2019-04-21 23:57 ` Drew Adams
2019-04-22 9:24 ` Dmitry Gutov
2019-04-22 11:18 ` Drew Adams
2019-04-29 19:20 ` npostavs
2022-01-22 15:29 ` Lars Ingebrigtsen
2022-01-22 16:13 ` Drew Adams
2019-04-30 2:29 ` Drew Adams [this message]
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=ba5742e5-410e-467f-9d17-d3fc690827e8@default \
--to=drew.adams@oracle.com \
--cc=35354@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=npostavs@gmail.com \
/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).