GNU bug report logs - #31492
26.1; query-replace-regexp undo fails in regexps w/o printable chars

Previous Next

Full log

Message #20 received at 31492 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tino Calancha <tino.calancha <at> gmail.com>
Cc: 31492 <at> debbugs.gnu.org
Subject: Re: 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 <tino.calancha <at> gmail.com>
> Date: Sat, 19 May 2018 10:46:10 +0900 (JST)
> cc: Tino Calancha <tino.calancha <at> gmail.com>, 31492 <at> debbugs.gnu.org
> 
> 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.

Previous Next

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