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: Thu, 24 Jun 2021 22:35:45 +0800 Message-ID: <874kdnwcse.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> <87o8c0r801.fsf@localhost> <83r1gvtnr4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22826"; 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 Thu Jun 24 16:36:12 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 1lwQSi-0005jp-GL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Jun 2021 16:36:12 +0200 Original-Received: from localhost ([::1]:44650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwQSh-0005CR-Em for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Jun 2021 10:36:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32862) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lwQSY-0005Aq-BY for bug-gnu-emacs@gnu.org; Thu, 24 Jun 2021 10:36:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60354) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lwQSY-0001Ok-3R for bug-gnu-emacs@gnu.org; Thu, 24 Jun 2021 10:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lwQSX-0003RO-W3 for bug-gnu-emacs@gnu.org; Thu, 24 Jun 2021 10:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Jun 2021 14:36: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.162454535813214 (code B ref 48740); Thu, 24 Jun 2021 14:36:01 +0000 Original-Received: (at 48740) by debbugs.gnu.org; 24 Jun 2021 14:35:58 +0000 Original-Received: from localhost ([127.0.0.1]:43667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwQSP-0003Qx-IA for submit@debbugs.gnu.org; Thu, 24 Jun 2021 10:35:58 -0400 Original-Received: from mail-lf1-f52.google.com ([209.85.167.52]:36771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwQSM-0003QZ-Qw for 48740@debbugs.gnu.org; Thu, 24 Jun 2021 10:35:51 -0400 Original-Received: by mail-lf1-f52.google.com with SMTP id d16so10663518lfn.3 for <48740@debbugs.gnu.org>; Thu, 24 Jun 2021 07:35:50 -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; bh=Q3pLVJ0BJKHh/7MozZcRf+/C22DdRsfA6RDUpLyOpr8=; b=CVOvyTMFOYUg/rZHTr3ci5ZUQc1x+60ypCCypXXKNUQC2huLXI7zuw2yBJs8VnPmuS 925I0ybno1mE/eLcO/gu2lEv4YKIEme8bdkxfZlV6bGMgUlOVq0qvQTokwgAMLLrnh+d DdY+sDZT2U0KyzFoZ9ywsQ0Jz1to/OjObilVgCCV4DyP2MyA81x+KT8k8yrRtPqrmrT4 cS1UXxUsrPO+gzZ+Qdr+6IpRmSwtMMImct1fnGBkO4JyIMgqYtmvpKMU4AM4tu5ES0XR fZe9XHVS9WV1QR2JkmkGpW9DoBY4fY7og4578V/f6UPVL50exEUzjwjxwaGOLDe4Oj1T gF9A== 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; bh=Q3pLVJ0BJKHh/7MozZcRf+/C22DdRsfA6RDUpLyOpr8=; b=URXcogPv02Zw7H1rLKeg/Yc5t69Hqua+bJ8+MleWuvlgC2MsSBDdibXPhiQt4Lq2eU iD2nanzLZHPpXvxCW0LVfceBfrMhSKom7AX2fEqSxmHaj9kpYnaCzGlL5XlWIdHmjsS6 Qq2nAoLPdQ7VQWoiD7dWxgMXswODa+YLX3nk6G74kl9L2kEYhshEALiPCkLGsy7q04L3 Q7wjRmosL6NOYAo6l6R/dsMSvOxhHOxvHagPlxG/uwnR3GTrGpy+AqugNAQt5ndf9wez vu24uuhy14KuqXhDq4wvYW8GKOxxi6ZlCX3uM5rAp0sSGIjTnWS8RwKzilx73LSl0dHC tvmQ== X-Gm-Message-State: AOAM530OBZWHmMut64QAiB/dzurkrZV/0eI1QXi791aPDiBZIFRLyBER ko+fVW86xiYDjB7YxvQOErcgml8xZ+o= X-Google-Smtp-Source: ABdhPJyw/l4m/0WCth+hQAjCEo1S0qgkvJAPzocTKRM5OxGQoSV3+Y94TFf1b+Xf2zUUQzOQagjDUA== X-Received: by 2002:a05:6512:c4:: with SMTP id c4mr4303762lfp.328.1624545344571; Thu, 24 Jun 2021 07:35:44 -0700 (PDT) Original-Received: from localhost ([91.210.107.197]) by smtp.gmail.com with ESMTPSA id a4sm195855lfr.210.2021.06.24.07.35.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 07:35:43 -0700 (PDT) In-Reply-To: <83r1gvtnr4.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:208927 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii 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. >> 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. In any case, changing concat to format fixed the observed problem. > 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. 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. Best, Ihor --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-src-fns.c-Fconcat-Update-docstring.patch >From 4cf994cdb3cf9ca07ddfa53bc85d7daa07e7c9cc Mon Sep 17 00:00:00 2001 Message-Id: <4cf994cdb3cf9ca07ddfa53bc85d7daa07e7c9cc.1624545283.git.yantar92@gmail.com> From: Ihor Radchenko Date: Thu, 24 Jun 2021 22:33:08 +0800 Subject: [PATCH] src/fns.c (Fconcat): Update docstring * src/fns.c (Fconcat): Note that composition values may not remain eq in return value of concat. See bug#48740. --- src/fns.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/fns.c b/src/fns.c index a178216622..73669287c9 100644 --- a/src/fns.c +++ b/src/fns.c @@ -672,6 +672,9 @@ DEFUN ("concat", Fconcat, Sconcat, 0, MANY, 0, doc: /* Concatenate all the arguments and make the result a string. The result is a string whose elements are the elements of all the arguments. Each argument may be a string or a list or vector of characters (integers). + +Values of `composition' property of the result are not guaranteed to +be `eq'. usage: (concat &rest SEQUENCES) */) (ptrdiff_t nargs, Lisp_Object *args) { -- 2.31.1 --=-=-=--