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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Not sure I understand: ideas about what?  The basic problem is that
> display of static compositions requires the values of the composition
> property to be 'eq'.  Due to implementation details, when you break a
> string with that property into 2 or more parts, the property value(s)
> could get copied, in which case they will no longer be 'eq'.  What
> else is needed to understand this problem?

Sorry, I was not very clear describing what I observe.

I found two strange things:

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.

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

   (concat
                   (substring x 0 (match-end 1))
                   (unless (string-empty-p org-agenda-todo-keyword-format)
                     (format org-agenda-todo-keyword-format
                             (match-string 2 x)))
                   ;; Remove `display' property as the icon could leak
                   ;; on the white space.
                   (org-add-props " " (org-plist-delete (text-properties-at 0 x)
                                                        'display))
                   (substring x (match-end 3)))

   During debugging, the composition property was always within a single
   interval except after running concat. Only the return value of concat
   had the composition split into to intervals.
   
   After replacing (concat ...) with (format "%s%s%s" ...), the
   composition was kept in a single interval and I found no issue with
   rendering.

   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.

Best,
Ihor