[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35354: 26.2; `dired-do-query-replace-regexp': How to replace only wo
From: |
Drew Adams |
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@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.