GNU bug report logs - #20153
24.4.91; destructive add-face-text-property and string deep copying

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Oleh Krehel <ohwoeowho <at> gmail.com>
Cc: 20153 <at> debbugs.gnu.org
Subject: Re: bug#20153: 24.4.91; destructive add-face-text-property and
 string deep copying
Date: Wed, 09 Oct 2019 04:25:04 +0200

Oleh Krehel <ohwoeowho <at> gmail.com> writes:

> Here's an example of what I'm trying to do:
>
> (setq test-str-1
>       #(";; This `is' a test"
>         0 3 (fontified nil face font-lock-comment-delimiter-face)
>         3 9 (fontified nil face font-lock-comment-face)
>         9 11 (fontified nil face (font-lock-constant-face font-lock-comment-face))
>         11 19 (fontified nil face font-lock-comment-face)))
> (setq test-str-2 (concat test-str-1))
> (add-face-text-property 0 (length test-str-2) 'foobar t test-str-2)
>
> I would like to modify `test-str-2' without touching `test-str-1'.
> For that, I either need `add-face-text-property' to be non-destructive,
> either w.r.t. the string or at least w.r.t. the properties of the
> string, or a way to deep-copy a string.

It's this code (in add_properties):

		/* The previous value is a list, so prepend (or
		   append) the new value to this list. */
		if (set_type == TEXT_PROPERTY_PREPEND)
		  Fsetcar (this_cdr, Fcons (val1, Fcar (this_cdr)));
		else
		  nconc2 (Fcar (this_cdr), list1 (val1));

But changing that would have pretty far-reaching consequences.  I wonder
whether instead Fadd_face_text_property should just (when called with a
string parameter) just copy the `face' property list first?  That should
avoid the problem and not lead to any general slowdown.

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