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: Sat, 14 Aug 2021 10:12:54 +0300 Message-ID: <83h7fsbitl.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38726"; 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 Sat Aug 14 09:14: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 1mEnrv-0009sX-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 09:14:11 +0200 Original-Received: from localhost ([::1]:38542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEnru-0003HK-Cf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 03:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEnrm-0003GW-Ne for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 03:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEnrm-0008A3-EQ for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 03:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEnrm-0003Z0-3J for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 03:14: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: Sat, 14 Aug 2021 07:14: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.162892519213616 (code B ref 47711); Sat, 14 Aug 2021 07:14:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 07:13:12 +0000 Original-Received: from localhost ([127.0.0.1]:43470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnqy-0003XW-Im for submit@debbugs.gnu.org; Sat, 14 Aug 2021 03:13:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnqx-0003X9-3n; Sat, 14 Aug 2021 03:13:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43950) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEnqr-0007Pp-6e; Sat, 14 Aug 2021 03:13:05 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2698 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 1mEnqq-0006TB-UW; Sat, 14 Aug 2021 03:13:05 -0400 In-Reply-To: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> (message from Dmitry Gutov on Sat, 14 Aug 2021 05:47:43 +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:211808 Archived-At: > From: Dmitry Gutov > Date: Sat, 14 Aug 2021 05:47:43 +0300 > Cc: Stefan Monnier , 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > > I thought I explained the problem with this previously. > > It's basically this: we cannot mutate what we don't own. Across all of > completion functions out there, there will be such that return "shared" > strings (meaning, not copied or newly allocated) from their completion > tables. And modifying them is bad, with consequences which can present > themselves in unexpected, often subtle ways. > > Since up until now completion-pcm--hilit-commonality copied all strings > before modifying, completion tables such as described (with "shared" > strings) have all been "legal". Suddenly deciding to stop supporting > them would be a major API breakage with consequences that are hard to > predict. And while I perhaps agree that it's an inconvenience, I don't > think it's a choice we can simply make as this stage in c-a-p-f's > development. This sounds like an argument against Daniel's approach as well, no? Because if a completion API returns strings it "doesn't own", there will be restrictions on Lisp programs that use those strings, because those Lisp programs previously could do anything they liked with those strings, and now they cannot. Or am I missing something? > 1. (setq s (symbol-name 'car)) > > 2. (put-text-property 1 3 'face 'error s) > > 3. Switch to a buffer in fundamental mode > > 4. (insert (symbol-name 'car)) --> see the error face in the buffer > > Now imagine that some completion table collects symbol names by passing > obarray through #'symbol-name rather than #'all-completions, and voila, > if the completion machinery adds properties (any properties, not just > face) to those strings, you have just modified a bunch of global values. > That's not good. How is this different from Daniel's proposal of returning the original strings? AFAIU, he just shifts the responsibility from the completion code to the caller of the completion code, but basically leaves the problem still very much real and pretty much into our face.