From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.bugs Subject: bug#65105: Reusing the same string as 'display on consecutive characters evades display Date: Sat, 5 Aug 2023 16:49:33 -0400 Message-ID: References: <83tttdqpko.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6814890C-3BB7-494D-9C63-3480D5FC3E22" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65105@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 05 22:50:26 2023 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 1qSOEE-0008lK-G6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Aug 2023 22:50:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSODs-0006dt-2i; Sat, 05 Aug 2023 16:50:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSODq-0006da-8R for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2023 16:50:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qSODp-0002mw-WE for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2023 16:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qSODp-0006u9-SI for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2023 16:50:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: JD Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Aug 2023 20:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65105 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 65105-submit@debbugs.gnu.org id=B65105.169126859726526 (code B ref 65105); Sat, 05 Aug 2023 20:50:01 +0000 Original-Received: (at 65105) by debbugs.gnu.org; 5 Aug 2023 20:49:57 +0000 Original-Received: from localhost ([127.0.0.1]:58263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSODk-0006tl-Cx for submit@debbugs.gnu.org; Sat, 05 Aug 2023 16:49:56 -0400 Original-Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]:55603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qSODg-0006tV-T2 for 65105@debbugs.gnu.org; Sat, 05 Aug 2023 16:49:55 -0400 Original-Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-77ac14ff51bso127470539f.3 for <65105@debbugs.gnu.org>; Sat, 05 Aug 2023 13:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691268587; x=1691873387; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=AbNuIJ3tsC5b9gRwTBapuxg8Av+B1mpf2x9NWU1e4m8=; b=XavQd6X3wmlnvGiK6fF9b1EAb3bI+QW84X82iJkm4bSg2PsUnu1Bnnmp2eMmsgaTP1 03iHt3kQMfV2QpfsYIbf733ciqMGSGw2pgGszZXxM7gS0MvbQ+MsraXBgMGV6K0VsU2Q IIp02DXCYPgF0e1NGqEhmKpl2UVsjufxq5ncIN3E1U65mgktDgdkicpP3a19XGN3jb7e rxI8di1P4HUH3ypRREyf/M+tjY6Ds8sewdqGHT6vsQXLbUelKzxDCuRLWwdBGcE2S7Ec xwXDh1m10Vg8rAq1HMj3LXSpKTF/mvLevtwjlyMY8StV6y56BGPd/OXz47dGd0zcwQzV SNrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691268587; x=1691873387; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AbNuIJ3tsC5b9gRwTBapuxg8Av+B1mpf2x9NWU1e4m8=; b=igt/XJBLGpWuFADdWrHMVOoQJh3MjZoC1PfVKTDLqDTGjlcLiirV9KgbddkioMaJL7 kS1999UM6C9Cthq/hl4gYwNDgphbTZUGMDNcWk3mW6NXW5OXcBw1iI73qSRsGx0J7wpE xYg5rLn55xEyRz82QKzSuZcDU+mIMqm4nXaTYp+GGuz1KboP41MllDZYqvv52snOdJvW g5gyYzToez41aPgKC5d1L6oIuss2x6WyEK7Kn7iP1nuVZziGTSCRC0ergsa8PnmNVcq7 eWQQ798mjz2VAoH91tYsv3DYEUCeeDO9t0glTkoBGEMggc0crSalx+jDkIxAD/QMbTyA 2yew== X-Gm-Message-State: AOJu0YxyE41/4GLosh8qOl7/sDnWQ5qwwNaSnvlnO6e/U0FmJk8zKonW e1CmEQ+C9cU7Lh5mcIOIgtY= X-Google-Smtp-Source: AGHT+IHr1H82qSGAI7oPTY7aaIapnFq3LWQAU2GKA72Z3oZT6UlwLB6bTP6eVCj+fjmDpXX+L2UOXQ== X-Received: by 2002:a05:6e02:1a89:b0:345:a6c5:1ce8 with SMTP id k9-20020a056e021a8900b00345a6c51ce8mr7200865ilv.14.1691268587102; Sat, 05 Aug 2023 13:49:47 -0700 (PDT) Original-Received: from smtpclient.apple (cm-24-53-184-115.buckeyecom.net. [24.53.184.115]) by smtp.gmail.com with ESMTPSA id gh7-20020a056638698700b0042b6f103e62sm1363917jab.133.2023.08.05.13.49.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Aug 2023 13:49:46 -0700 (PDT) In-Reply-To: <83tttdqpko.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.700.6) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266817 Archived-At: --Apple-Mail=_6814890C-3BB7-494D-9C63-3480D5FC3E22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 5, 2023, at 3:03 PM, Eli Zaretskii wrote: >=20 > tags 65105 notabug > thanks >=20 >> From: JD Smith >> Date: Sat, 5 Aug 2023 14:35:23 -0400 >>=20 >> Evaluate: >>=20 >> (let ((s1 "test1") >> (s2 "test2")) >> (insert "\n" >> (propertize " " 'display s1) >> (propertize " " 'display s1) >> (propertize " " 'display s2) >> (propertize " " 'display s1))) >>=20 >>=20 >> The first space display does not take effect, since the s1 string is = used for two consecutive characters. This has a practical impact for = font-lock backends that use the =E2=80=98display text-property and would = like to minimize string allocation. =20 >=20 > Emacs cannot distinguish between two consecutive characters having > each a text property with the same value, and two characters having > the same property. If you think about this for a moment, you will > understand why: we use intervals for text properties, so two adjacent > intervals with the identical property values and one interval with > that same value are indistinguishable (and in fact Emacs optimizes > this during GC by making just one interval from these two). >=20 > This is not a bug. Aha, thanks. It does make sense from an optimization standpoint to = =E2=80=9Cgang=E2=80=9D properties in this manner. Are you aware of any = approach that allow re-using a string for =E2=80=98display, but permits = consecutive intervals to remain distinct?= --Apple-Mail=_6814890C-3BB7-494D-9C63-3480D5FC3E22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 5, = 2023, at 3:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:

tags 65105 notabug
thanks

From: JD Smith = <jdtsmith@gmail.com>
Date: Sat, 5 Aug 2023 14:35:23 = -0400

Evaluate:

(let ((s1 = "test1")
     (s2 "test2"))
 (insert = "\n"
         (propertize = " " 'display = s1)
         (propertize = " " 'display = s1)
         (propertize = " " 'display = s2)
         (propertize = " " 'display s1)))


The first space display does not take = effect, since the s1 string is used for two consecutive characters. =  This has a practical impact for font-lock backends that use the = =E2=80=98display text-property and would like to minimize string = allocation.  

Emacs = cannot distinguish between two consecutive characters having
each a text property with the same value, = and two characters having
the = same property.  If you think about this for a moment, you = will
understand why: we use = intervals for text properties, so two adjacent
intervals with the identical property = values and one interval with
that = same value are indistinguishable (and in fact Emacs optimizes
this during GC by making just one interval = from these two).

This is = not a bug.

Aha, thanks.  It = does make sense from an optimization standpoint to =E2=80=9Cgang=E2=80=9D = properties in this manner.  Are you aware of any approach that = allow re-using a string for =E2=80=98display, but permits consecutive = intervals to remain distinct?
= --Apple-Mail=_6814890C-3BB7-494D-9C63-3480D5FC3E22--