From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: 48740@debbugs.gnu.org
Subject: bug#48740: 28.0.50; Composition text property is not always honoured
Date: Mon, 21 Jun 2021 15:18:07 +0300 [thread overview]
Message-ID: <83r1gvtnr4.fsf@gnu.org> (raw)
In-Reply-To: <87o8c0r801.fsf@localhost> (message from Ihor Radchenko on Sun, 20 Jun 2021 21:16:46 +0800)
> 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.
next prev parent reply other threads:[~2021-06-21 12:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-30 7:35 bug#48740: 28.0.50; Composition text property is not always honoured Ihor Radchenko
2021-05-30 11:10 ` Eli Zaretskii
2021-05-30 13:08 ` Ihor Radchenko
2021-05-30 13:52 ` Eli Zaretskii
2021-05-30 15:13 ` Ihor Radchenko
2021-05-30 15:58 ` Eli Zaretskii
2021-05-31 13:00 ` Ihor Radchenko
2021-05-31 14:32 ` Eli Zaretskii
2021-06-01 14:28 ` Ihor Radchenko
2021-06-01 15:25 ` Eli Zaretskii
2021-06-01 16:25 ` Eli Zaretskii
2021-06-20 11:24 ` Ihor Radchenko
2021-06-20 11:53 ` Eli Zaretskii
2021-06-20 13:16 ` Ihor Radchenko
2021-06-21 12:18 ` Eli Zaretskii [this message]
2021-06-24 14:35 ` Ihor Radchenko
2021-06-24 16:06 ` Eli Zaretskii
2021-10-24 7:42 ` Stefan Kangas
2021-10-24 12:04 ` Eli Zaretskii
2021-10-24 12:27 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83r1gvtnr4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=48740@debbugs.gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.