[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20153: 24.4.91; destructive add-face-text-property and string deep c
From: |
Lars Ingebrigtsen |
Subject: |
bug#20153: 24.4.91; destructive add-face-text-property and string deep copying |
Date: |
Wed, 09 Oct 2019 04:25:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Oleh Krehel <ohwoeowho@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
- bug#20153: 24.4.91; destructive add-face-text-property and string deep copying,
Lars Ingebrigtsen <=