Subject: bug#9871: `query-replace' and friends break text properties

From: Drew Adams <[email-masked]>
Date: Sun, 18 Aug 2019 17:57:18 -0700 (PDT)

> I guess the question becomes -- what text properties should be in the
> result?
> 
> If you have
> 
> (with-temp-buffer
>   (insert (propertize "hel" 'face 'bold))
>   (insert (propertize "lo" 'face 'underline))
>   (goto-char (point-min))
>   (replace-regexp "ell" "yes, well")
>   (buffer-string))
> 
> should "yes, well" be in bold or underline?  Or a mix?  I don't really
> think there's any solution here that will satisfy anybody.
> 
> But I guess it would make some sense to view this as "delete the text,
> and then pretend we're inserting text as if by `self-insert-command'",
> which would make the new text bold here.
> 
> I don't know...  all solutions here seem kinda ad hoc, so perhaps the
> current behaviour is the least surprising.  Any opinions?

I take a slightly different position from both
of you, I guess.

I'd say that the replacement text should replace
the text to replace as if `delete-selection-mode'
were turned on and you (1) selected the text to
replace and then ` yanked the replacement text
from the kill ring to replace it.  The text props
are copied to the kill-ring as part of the text.
And yanking the text gives you copies that also
have those text properties.  Why shouldn't the
same behavior be available for query-replace?

If a user specifies replacement text that has
text properties then it should be used as is:
its properties should remain when it takes the
place of text in the buffer.

E.g. Copy some buffer text that has properties
into the kill ring. Then use `M-%' and yank that
copied, propertized text as the replacement text.
The places where it now appears as replacement
should all have the same text properties.  But
they don't seem to.