bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]