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

[Tino Calancha]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, I see the problem now.
>
> However, isn't the root cause in replace--push-stack?
I am not sure; there is something else (see below).

> 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.
Yes, that is the logic.  The thing is, for some unknown reason to me,
the reported match-data is inexact when there are no printable chars
in the regexp (maybe it's expected and I am wrong on my assumptions).

> IOW, I'm afraid the looking-back solution is ad-hoc, and might not
> work in general, because the real problem is elsewhere.  WDYT?
Look what happen in these examples:

(with-temp-buffer
  (insert "foo")
  (goto-char 1)
  (progn (re-search-forward "o$" nil t)
         (save-match-data (replace-match "oZZZ"))
         (list (point) (match-beginning 0) (match-end 0))))
=> (7 3 7)

;; Now, a regexp with no printable chars

(with-temp-buffer
  (insert "foo")
  (goto-char 1)
  (progn (re-search-forward "$" nil t)
         (save-match-data (replace-match "ZZZ"))
         (list (point) (match-beginning 0) (match-end 0))))
=> (7 7 7)
;; If this would be (7 4 7), then we could use `looking-at'; we are to
;; the right of the replacement, then we use `looking-back'.
  

;; But the match was at 4 not at 7
(with-temp-buffer
  (insert "foo")
  (goto-char 1)
  (progn (re-search-forward "$" nil t)
         (list (point) (match-beginning 0) (match-end 0))))
=> (4 4 4)
;; We lost the information about the beginning of the match when
;; the regexps lack of printable characters.