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

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

[Štěpán Němec]

emacs -Q
(put-text-property (point-min) (point) 'oh-no! t)
M-<
M-% buffer RET fluffer RET y

Whoops, the property's gone in the replaced text.

The replacement commands should honour text properties just as
`self-insert-command' does.

-- 
Štěpán

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

[Lars Ingebrigtsen]

Štěpán Němec <stepnem@gmail.com> writes:

> emacs -Q
> (put-text-property (point-min) (point) 'oh-no! t)
> M-<
> M-% buffer RET fluffer RET y
>
> Whoops, the property's gone in the replaced text.
>
> The replacement commands should honour text properties just as
> `self-insert-command' does.

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> 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.

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

[Štěpán Němec]

On Sun, 18 Aug 2019 17:03:28 -0700
Lars Ingebrigtsen wrote:

> 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.
                                                    ^^^^^^^
I assume you meant "everybody".

> 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.

Yes it would. I also think that the straightforward case where all the
text has the same value for a property will be much more frequent than
your contrived example (note my property wasn't even visible at all; in
case of font-locking for example I'd expect the result to get
refontified as usual anyway).

> I don't know...  all solutions here seem kinda ad hoc, so perhaps the
> current behaviour is the least surprising.  Any opinions?

I definitely don't consider it the least surprising, but I guess you're
rather asking for the opinion of other people.

On Sun, 18 Aug 2019 17:57:18 -0700 (PDT)
Drew Adams wrote:

[...]

> 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.

[...]

Sure. For the yanking (i.e., interactive) case there's also
`yank-handled-properties' and `yank-excluded-properties'.

-- 
Štěpán

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

[Lars Ingebrigtsen]

Štěpán Němec <stepnem@gmail.com> writes:

> Yes it would. I also think that the straightforward case where all the
> text has the same value for a property will be much more frequent than
> your contrived example (note my property wasn't even visible at all; in
> case of font-locking for example I'd expect the result to get
> refontified as usual anyway).

I just used a face because that's visible; the same applies to any text
property.

Thinking about it a bit more, I don't really feel that
delete-then-insert semantics will be very nice as a feature, either.

(with-temp-buffer
  (insert (propertize "hello" 'face 'bold))
  (goto-char (point-min))
  (replace-regexp "hello" "hey")
  (buffer-string))

If you replace a phrase that has one face with a different phrase, if
text properties are preserved, surely you'd expect that "hey" to also be
bold.  But it won't be, since the "hello" was deleted first and then
"hey" was inserted.

So I don't really think there's any way to DWIM here that is "what I
mean", and if you want to copy over text properties in one form of
another, you have to write some code to express what you want to have
happen.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no