From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 14:22:04 +0300 Message-ID: <1982cc2e-f955-7f15-0781-65cdbbe96759@yandex.ru> 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> <83h7fsbitl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37379"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, 47711@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 14 13:23:11 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 1mErks-0009Up-S2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 13:23:10 +0200 Original-Received: from localhost ([::1]:58782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mErkq-0006Is-Tc for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 07:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mErkk-0006IP-T8 for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 07:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60364) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mErkk-0004NM-Hm for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 07:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mErkk-00069V-9u for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 07:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 11:23: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.162894013623569 (code B ref 47711); Sat, 14 Aug 2021 11:23:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 11:22:16 +0000 Original-Received: from localhost ([127.0.0.1]:43675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErk0-000684-AV for submit@debbugs.gnu.org; Sat, 14 Aug 2021 07:22:16 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:45664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErjw-00067h-K4; Sat, 14 Aug 2021 07:22:14 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id v4so9665078wro.12; Sat, 14 Aug 2021 04:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=KtOGOSadTAivI+sMaG6Z6n5tKwV9ww1gyYmNIGTGVZyB97ya1xbDJRnwcp0kzKRZEY PoNmwXjiN84dxzXXdFsLHZu1dY+dFGi8R+G7VsmF9uu75doIV470wK+vvrNkIGqq5oF7 5lXdH2Zh87DLnGcJWdKBHcoSyjd4NDQ54LKV96L/lCRfqUtrWjC2IEgBG8CnZBX/LVse Ge/J716dgLZRPAGc9w0Pg4X5tYrIVs7if5uWoY04HN0OQ42Hq3L9HIAtXaoT1kwoF8Vq ZfznUT8rQWZZEA50PfQhafBRFekQ+zBB+4N3WW2a5D48rjEUVEaxUnb1zKX8Qtxk+LVd YErw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=dfPwo/eCR6EhPrIzmHuvvv2z/+3RiB3BL5GJU7psxKEWglwZY+MelPg/7InHoF1C2F XQTY8yYAyKsBBxRcSSpb0tEgGiwLMg1AVnu28OXDWCDqiYs2wg4IH+7Q1wlDqo3wR1ZM PoLwudx744Lbh1EScmPHWOc1C5nOVA7lBhOm4qB6qYyNOJnLntHO1TBqA0trcAvCHvG9 vG9ECTnNVytY7e2ukBDICfLhCe4fjeIto10DmM442xQrlqfi1RTqtiBN3R8tlL3lcpsm AWAha/yueYlnE43yJ8NQgrX0I3BvoLnsU1bN3/vhJUATlXq1WXdcmTJ89gojqf/frn4n lL2A== X-Gm-Message-State: AOAM533B540ekMmbfMcfwwVHVzpDJYcrGbRmNq8CI3zwJAy4vletyysy goddsQyHDv4WAT5dFtbWduf10t6/YhI= X-Google-Smtp-Source: ABdhPJzjf7FPFGHs13PIjXxd+flbf6DnhuFohEbMnGizSM9H9gQDNOAyBHclQjs/QeqAc28qCLDrEA== X-Received: by 2002:a05:6000:18a4:: with SMTP id b4mr8133637wri.162.1628940126633; Sat, 14 Aug 2021 04:22:06 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q75sm4370937wme.40.2021.08.14.04.22.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 04:22:05 -0700 (PDT) In-Reply-To: <83h7fsbitl.fsf@gnu.org> Content-Language: en-US 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:211820 Archived-At: On 14.08.2021 10:12, Eli Zaretskii wrote: >> 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? Good question. It is not. The completion tables described above have all been doing "legal" things, in our general understanding. But any callers of completion-all-completions were never really allowed to modify the returned strings (those still were strings that code "doesn't own"). Of course, some of those callers (I don't know any, though) might have taken advantage of being able to modify the strings with impunity because of completion-all-completions' implementation detail, but they'll have a chance to clean up their act when switching to completion-filter-completions. >> 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. This is a shift of responsibility in the right direction. The callers might as well do the string copying when needed, but the fact of the matter is, they usually only need to "copy" 20-100 strings (or however many is displayed), if they need to modify them at all. That's where we win: copying 100 strings is better than copying 10000. Gotta run now, will reply to other email later.