bug#48740: 28.0.50; Composition text property is not always honoured

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> CC: 48740@debbugs.gnu.org
> Date: Sun, 20 Jun 2021 21:16:46 +0800
> 
> 1. After manually changing the todo state from TODO to ONGOING in
>    inbox.org, the composition property appears to be broken. Yet, the
>    ONGOING is replaced by 👷:
> 
>    #("* ONGOING" 0 1 (...) 2 5 (... composition (0 7 [128119]) 
> prettify-symbols-start 3 prettify-symbols-end 10
>    face org-todo) 5 9 (... composition (0 7 [128119]) prettify-symbols-start 
> 3 prettify-symbols-end 10 face
>    org-todo))
> 
>    I know no way to know if the property intervals are split because
>    composition properties are not eq there is some other properties are
>    not eq.
> 
>    Now, after writing this, I start to believe that composition is still
>    eq in this kind of situation, because, as you have explained, the
>    composition would not render otherwise.

Yes, it must be eq.

What I don't understand is why the property is broken into two
intervals.  You have only one word, ONGOING, so why is the property
divided into 2?

> 2. The following code in org-agenda-highlight-todo unexpectedly breaks
>    the composition into two intervals with composition values becoming
>    not eq:

Why is this code needed?  And why not put the property on the word
after concatenating, to avoid the issue?

>    So, it appears to me that concat somehow messed up the composition
>    proprety. May it be the case?
> 
>    I found a suspicious code in C concat function (fns.c:735):
> 
>         /* If successive arguments have properties, be sure that the
>            value of `composition' property be the copy.  */
>         if (last_to_end == textprops[argnum].to)
>           make_composition_value_copy (props);
> 
>     I can barely understand what is going on in the C code of concat,
>     but if it copies the composition property in some cases, we might
>     get the issue at hand.

It looks like some other use cases want to keep the compositions
separate when a string is generated by 'concat'.

I don't want to make low-level changes in how static compositions are
treated, so I'd prefer that this problem be fixed on the application
level.