From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#48740: 28.0.50; Composition text property is not always honoured Date: Sun, 20 Jun 2021 21:16:46 +0800 Message-ID: <87o8c0r801.fsf@localhost> References: <87im30ad2g.fsf@localhost> <837djg4gvq.fsf@gnu.org> <87wnrgtlln.fsf@localhost> <8335u449de.fsf@gnu.org> <87pmx8tfub.fsf@localhost> <83y2bw2oyr.fsf@gnu.org> <87eedn12j6.fsf@localhost> <835yyz2ctp.fsf@gnu.org> <878s3tbqvx.fsf@localhost> <83wnrdzjxe.fsf@gnu.org> <87v968ok1k.fsf@localhost> <835yy8vjje.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11925"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48740@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 20 15:17:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1luxKA-0002tf-Fi for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Jun 2021 15:17:18 +0200 Original-Received: from localhost ([::1]:52596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luxK9-0000k5-3V for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Jun 2021 09:17:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luxJu-0000jl-IO for bug-gnu-emacs@gnu.org; Sun, 20 Jun 2021 09:17:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49928) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1luxJt-0007Km-R9 for bug-gnu-emacs@gnu.org; Sun, 20 Jun 2021 09:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1luxJt-0003qB-L7 for bug-gnu-emacs@gnu.org; Sun, 20 Jun 2021 09:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Jun 2021 13:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48740 X-GNU-PR-Package: emacs Original-Received: via spool by 48740-submit@debbugs.gnu.org id=B48740.162419501714750 (code B ref 48740); Sun, 20 Jun 2021 13:17:01 +0000 Original-Received: (at 48740) by debbugs.gnu.org; 20 Jun 2021 13:16:57 +0000 Original-Received: from localhost ([127.0.0.1]:33241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luxJo-0003pq-VB for submit@debbugs.gnu.org; Sun, 20 Jun 2021 09:16:57 -0400 Original-Received: from mail-lj1-f171.google.com ([209.85.208.171]:41814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1luxJm-0003pc-Gn for 48740@debbugs.gnu.org; Sun, 20 Jun 2021 09:16:56 -0400 Original-Received: by mail-lj1-f171.google.com with SMTP id z22so21094211ljh.8 for <48740@debbugs.gnu.org>; Sun, 20 Jun 2021 06:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:cc:date:message-id :mime-version:content-transfer-encoding; bh=FzVrPnZgoIC2u/8jX+PxyxFCItjSUuf5Vyu4qAH7egE=; b=bK80FGMz9m+Qe1kdNohCXHrD38IYRty/VW/w8K7AsQBQZHSd7Dh7lfHmXVxgE7/NWp jLYt8mTquSqQjuNglM04FPGEL9+Eloj13M5kUN+8CkyoWwrr6V9eQK/q9UI6sL/vXUE6 q13bk/G4TZWtbNs6g0zcoxpxKZMu2EnUhTZrcpsivMQAjE4nAFqTywU+5SBGskrADuVK LVAIUyfsH56dVbwS/YGa3Ee6YZkaKKxTgfgILhATq4yRJu8jL3B3pS+ZsAA2ofXoXWZx F+xrBit4edwDJCDEBYpTKVCz0eFNtMHkER6nI3IIE+7I1m0a14Vz0BZWH+5SXVjumlcn 8GfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:cc:date :message-id:mime-version:content-transfer-encoding; bh=FzVrPnZgoIC2u/8jX+PxyxFCItjSUuf5Vyu4qAH7egE=; b=DHH3Q0d6JFmg/2Df8hoVRSZlVDI921Zt/A0a4BanXQnEAYJZBIluX9CZg7gEJO6kwO NWLVUrN/qnhy+l4W3M0vn/sRSMp4qEib/I3vP5nxzxyYn2LyF7iYV+tmcsaH5pcwIWGL yGO4/qKT/TUhX0Xfx7YCw6M8Ty+nVo/LaovK426mHDgUf87MniYOjnnuUFessDcLHTh1 ercUX6m6SnDa0nkiWZxb+or0GqJ2y4Ot2oLPdnwQaCIldnFTiQnyTH29KGUhhZtgKuZ8 UzemIF6D4rgGzgRE0aeagzUdE9RcDmLWHzfTNlrrp4/a+XJLrItLqZwYDSZEVRZdTKOJ 7acg== X-Gm-Message-State: AOAM532cC4gE/oHcSnhokm9hqSWOhhdFyHk7Cs6KsI8YCz1r7YOpOrd0 5Nvb673ERsueGkidMjwl3tg= X-Google-Smtp-Source: ABdhPJyVTPOGGNZVkHqkMe6ojt2DbI6Cr0N9jBY9KpZGlQ8yGbAE8Ug6ODWE7ylCLqYwBWDOrlQgCQ== X-Received: by 2002:a2e:2f07:: with SMTP id v7mr17728447ljv.308.1624195008368; Sun, 20 Jun 2021 06:16:48 -0700 (PDT) Original-Received: from localhost ([158.255.2.9]) by smtp.gmail.com with ESMTPSA id bn23sm1793202ljb.48.2021.06.20.06.16.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Jun 2021 06:16:47 -0700 (PDT) In-Reply-To: <835yy8vjje.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208791 Archived-At: Eli Zaretskii 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 =F0=9F=91=B7: #("* ONGOING" 0 1 (...) 2 5 (... composition (0 7 [128119]) prettify-sym= bols-start 3 prettify-symbols-end 10 face org-todo) 5 9 (... composition (0 7 [128119]) prettify-symbols-star= t 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. =20=20=20 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 =3D=3D 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