From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 14:46:58 +0300 Message-ID: <83tujp8vd9.fsf@gnu.org> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14203"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 13:48:21 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 1mFb6K-0003Ux-SB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 13:48:20 +0200 Original-Received: from localhost ([::1]:45854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFb6J-0007iw-Qv for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 07:48:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFb63-0007h1-LU for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:48:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37124) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFb62-0002go-7S for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFb62-0002AZ-5X for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 07:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47711 X-GNU-PR-Package: emacs Original-Received: via spool by 47711-submit@debbugs.gnu.org id=B47711.16291144328258 (code B ref 47711); Mon, 16 Aug 2021 11:48:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 11:47:12 +0000 Original-Received: from localhost ([127.0.0.1]:48668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb5E-000298-7w for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:47:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb5D-00028o-G7; Mon, 16 Aug 2021 07:47:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44640) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFb57-00028Z-QC; Mon, 16 Aug 2021 07:47:05 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2095 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFb57-0003EM-Ac; Mon, 16 Aug 2021 07:47:05 -0400 In-Reply-To: <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> (message from Dmitry Gutov on Mon, 16 Aug 2021 06:17:32 +0300) 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:211985 Archived-At: > Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 16 Aug 2021 06:17:32 +0300 > > On 14.08.2021 14:29, Eli Zaretskii wrote: > > Text properties are stored separately from the string, so I don't > > think adding properties can in general be referred to as "change". > > Are you thinking of C strings? No, about the implementation of Lisp strings in Emacs. > Lisp strings carry text properties in addition to the array of > characters. It doesn't really matter where in the memory the properties > and the characters reside. Well, it does, at least in some situations. The string text is not affected, and so the code which processes the string will not notice that it has a property about which that code has no idea. Only properties that are known to the processing code can affect it; non-standard properties private to some other code will generally pass unnoticed. > > Whether in some particular situation that could count as a "change" > > depends on that situation and on the particular property, of course. > > I was talking in the general sense: modifying a value. > > One can talk about whether a certain modification matters in certain > situations, but that's not the way to discount a general principle. I didn't want to start a general philosophical discussion about string mutability. I hoped to provide input of specific practical use in the context of this discussion. If what I said is not useful, just disregard it. > > I'm not sure in the context of completion there's any reason to count > > as "change" adding properties that don't affect display. > > For the context in question, whether the properties affect display is > not particularly important. Properties affecting display just make it > easier to notice that something's wrong. Bug involving other properties > should be more difficult to investigate. Once again, if some code invents its private property, not used anywhere else and not documented anywhere else, then putting such a property on a string has very high chances of going unnoticed. I hope this consideration helps this discussion, because saying that properties change a string blurs the distinction between actually changing the string text or its properties that affect many parts in Emacs, and adding some obscure property that is not known to anyone.