[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31492: 26.1; query-replace-regexp undo fails in regexps w/o printabl

From: Eli Zaretskii
Subject: bug#31492: 26.1; query-replace-regexp undo fails in regexps w/o printable chars
Date: Sat, 19 May 2018 10:50:30 +0300

> From: Tino Calancha <address@hidden>
> Date: Sat, 19 May 2018 10:46:10 +0900 (JST)
> cc: Tino Calancha <address@hidden>, address@hidden
> The correct recipe is:
> M-<
> C-M-% \b RET foo RET SPC SPC
> U
> ;; All 'foo' keep there :-(

Thanks, I see the problem now.

However, isn't the root cause in replace--push-stack?  The relevant
element of the replacement stack (whose structure, btw, seems not to
be documented anywhere), is (4 4 *scratch*), whereas I'd expect to see
(1 4 *scratch) instead, because the replacement was at position 1;
then setting match-data from this would DTRT.

IOW, I'm afraid the looking-back solution is ad-hoc, and might not
work in general, because the real problem is elsewhere.  WDYT?

> This happen because the regexp "\b" has any printable character.

Why does it matter for \b to match a non-empty string?  The undo-all
command matches text against the _replacement_ string, not against the
original search string.  And the replacement string, "foo", is not
empty.  The problem here, AFAICT, is that we are looking for it in the
wrong place, and that happens because the replacement stack tells us
to look at position 4 instead of position 1.  Right?

> If we try instead:
> M-<
> C-M-% is\b RET foo RET SPC SPC
> U
> ;; Now all 'foo' are gone :-)

Yes, because in this case the replacement stack has the correct data.

reply via email to

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