GNU bug report logs - #9871
`query-replace' and friends break text properties

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9871 in the body.
You can then email your comments to 9871 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Štěpán Němec <stepnem <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: `query-replace' and friends break text properties
Date: Wed, 26 Oct 2011 00:20:35 +0200

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Štěpán Němec <stepnem <at> gmail.com>
Cc: 9871 <at> debbugs.gnu.org
Subject: Re: bug#9871: `query-replace' and friends break text properties
Date: Sun, 18 Aug 2019 17:03:28 -0700

Štěpán Němec <stepnem <at> 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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Štěpán Němec
 <stepnem <at> gmail.com>
Cc: 9871 <at> debbugs.gnu.org
Subject: RE: 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.

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

From: Štěpán Němec <stepnem <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9871 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9871: `query-replace' and friends break text properties
Date: Mon, 19 Aug 2019 10:43:49 +0200

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Štěpán Němec <stepnem <at> gmail.com>
Cc: 9871 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#9871: `query-replace' and friends break text properties
Date: Mon, 19 Aug 2019 13:37:08 -0700

Štěpán Němec <stepnem <at> 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

Previous Next

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