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 15:39:33 +0300 Message-ID: <83k0kl8sxm.fsf@gnu.org> References: <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> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31128"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru, larsi@gnus.org, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 14:40:14 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 1mFbuY-0007oK-Cf for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 14:40:14 +0200 Original-Received: from localhost ([::1]:42904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbuW-0006uR-JU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 08:40:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFbuN-0006sh-91 for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:40:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37326) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFbuN-00016S-2a for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFbuM-0008Dx-W1 for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:40: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 12:40: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.162911759631588 (code B ref 47711); Mon, 16 Aug 2021 12:40:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:39:56 +0000 Original-Received: from localhost ([127.0.0.1]:48871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbuF-0008DK-On for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:39:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbu8-0008Cs-5T; Mon, 16 Aug 2021 08:39:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46626) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbu1-00014t-Dy; Mon, 16 Aug 2021 08:39:41 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1381 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 1mFbu0-0000Ui-Sm; Mon, 16 Aug 2021 08:39:41 -0400 In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 12:52:58 +0200) 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:212005 Archived-At: > Cc: Dmitry Gutov , Lars Ingebrigtsen , > 47711@debbugs.gnu.org, 48841@debbugs.gnu.org, > Stefan Monnier , Eli Zaretskii > From: Daniel Mendler > Date: Mon, 16 Aug 2021 12:52:58 +0200 > > On 8/16/21 12:15 PM, João Távora wrote: > > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wrote: > > > >> There are serious drawbacks of attaching "private" string properties to > >> arbitrary strings. For once it complicates debugging seriously if there > >> are suddenly string properties attached to symbol names. It also leads > >> to a potential memory leak. > > > > Please, in the name of the sanity of this discussion, justify these two > > statements with examples or follow them with a clause like "because...". > > João, I am giving hard examples here. What is not an example about > "memory leak" or making debugging output verbose thanks to the attached > string properties? FWIW, I also don't understand how adding properties could cause a memory leak. When a string is GCed, its properties get GCed as well, all of them. Am I missing something? As to more difficult debugging, I think adding a couple of properties that have simple structure will not impair debugging too much. Strings with many properties are not uncommon in Emacs, so we already have to deal with that. > As I said, I will ensure that my API does not introduce performance > regressions. And since my new API performs strictly less work than your > proposal it will necessarily be faster if you consider only the > filtering, which is what matters for incrementally updating UIs. I would indeed suggest both to make sure there's no performance regressions, and would like to see some data similar to what João presented, which backs up your assessments about your proposal being faster. Since performance is the main motivation for these changes, I think it's important for us to be on the same page wrt facts related to performance, before we make the decision how to proceed. Thanks.