[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48740: 28.0.50; Composition text property is not always honoured
From: |
Eli Zaretskii |
Subject: |
bug#48740: 28.0.50; Composition text property is not always honoured |
Date: |
Mon, 21 Jun 2021 15:18:07 +0300 |
> 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.