[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9871: `query-replace' and friends break text properties
From: |
Drew Adams |
Subject: |
bug#9871: `query-replace' and friends break text properties |
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.