bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Thu, 24 Jun 2021 19:06:41 +0300

> From: Ihor Radchenko <yantar92@gmail.com>
> CC: 48740@debbugs.gnu.org
> Date: Thu, 24 Jun 2021 22:35:45 +0800
> 
> 
> [1:text/plain Hide]
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> As I understand, the composition in the two intervals remains the same.
> However, some other text properties differ, so the composition property
> is "spread" across the two intervals.

OK, so we understand that.  But when Emacs splits the interval because
other properties differ, it takes care of copying the same property
value to both intervals, so the values are 'eq'.

> >> 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?
> 
> The code formats todo keyword in agenda line according to
> org-agenda-todo-keyword-format. The function does not know if the passed
> string has composition property or not.

But the caller does.

> In any case, changing concat to format fixed the observed problem.

Yes, because 'format' attempts to preserve text properties.

> I understand. However, the problem is quite unexpected. I do not see how
> application can anticipate it. Probably, adding a note to docstring
> would be useful? Something like in the attached patch.

Fine with me, thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]