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#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Sat, 14 Aug 2021 05:47:43 +0300 Message-ID: <8a36e61a-1c5b-bf3b-a454-077348589c4f@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2901"; 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: Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 14 04:48: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 1mEjiV-0000eU-L1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 04:48:11 +0200 Original-Received: from localhost ([::1]:52028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEjiU-0005OA-Aq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Aug 2021 22:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEjiM-0005Nn-TU for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 22:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60057) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEjiM-0004kV-Lr for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 22:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEjiM-0005PP-Kg for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 22:48: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 02:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162890927420762 (code B ref 48841); Sat, 14 Aug 2021 02:48:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 02:47:54 +0000 Original-Received: from localhost ([127.0.0.1]:43367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjiD-0005Om-GA for submit@debbugs.gnu.org; Fri, 13 Aug 2021 22:47:53 -0400 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:40490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjiC-0005OW-1a; Fri, 13 Aug 2021 22:47:52 -0400 Original-Received: by mail-wm1-f45.google.com with SMTP id f12-20020a05600c4e8c00b002e6bdd6ffe2so5160108wmq.5; Fri, 13 Aug 2021 19:47:51 -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=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=Vidv7X/VQNIy18MEfGR9+nO2HYx3p9uH5yds3+TK7an4SST2+36hNaFlToeGos1yzU ZXPEaOpJzr5nAm2atp8TRLaxcrJx59uNbGTcfk7ElXQLM6craANPxqMRQ/TJbw12OkVS lC0+2s9E6OgAmxOnj8t2Qhui612cejdqTiSIhupU9/FRSTtmV0qUYMJmda0IWsImEzbn DKsFPCnqf7m0sx09tPSKXKlkBvncG41XVJ6Cq3K5sANAomQJa8sH4P9GAr6+2fVnmIX9 w8xO/J7VMNT6j80LLgl56LJNAtV57ifHaDToXoKmypw3CPOhSfbrl6x7N0bZIfhRQ7xR 2TFg== 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=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=nR1zS8Nn309e6wVeitw1G4GtSPeEcG9GrIwjnVhWO70ig2C6FOM97NZkOHB4MyExCs X/DPOTnUIk77LeUS5ETxtYZRizhEKjozvMkKAiWOH2VOxkBTWoJpsbeZaq+BtGp+eKeb hWvDeoVOCZ4faOBObfh9j2PgNAW6clgferd+ak0/cx8HUE1Hg706HUK32wirZWauT4zm kXzquiRez+FniGAL7lf5pkd26FbkrmgB03mTjrER/KDSwJUHGzKVEOdhV5LJ1EvlTmox JC592hdQW9AUDUNbVJncKNQoJ7tR8XDlj9TeiZ/OFnLqvYBmYDc5LvJDilhju+ZeA8n/ yhLw== X-Gm-Message-State: AOAM531g56FoYOaYmEL8muZY8+YnZJw7nkYCU37bqilNQgOB1iu8oIO1 4oK+xKI7C2XpW2L5of8woHtOyR7P9XU= X-Google-Smtp-Source: ABdhPJzxplFEaS0USQ1x53CqyR9NU8Z7vLpfrynY2I7Tg+tlEzk6uUD8ELyaLrcjfBvTR/qCtD+o/w== X-Received: by 2002:a1c:a743:: with SMTP id q64mr5205240wme.74.1628909266069; Fri, 13 Aug 2021 19:47:46 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l2sm3072055wme.28.2021.08.13.19.47.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 19:47:45 -0700 (PDT) In-Reply-To: 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:211798 Archived-At: Hi folks, Sorry I'm late to this party. On 13.08.2021 16:36, João Távora wrote: >>>> By separating the filtering and mutation >>>> (highlighting, scoring) my patch addresses the problem at hand in the >>>> proper way. >>>> [ ... ] >>>> Mutation would be a reasonable choice here if the problem could not be >>>> solved in a proper way. But in fact it can be solved in a proper way >>>> without mutating the strings at all as my patch shows. >>> "proper" is just an reasonably empty adjective. There are different ways to >>> go about this, of course. What's "proper" and isn't is hard to debate >>> objectively. >> You are contradicting yourself here. You agree that string mutation is >> better be avoid. If we define "proper" as avoids string mutation if this >> is easily possible, then my patch implements a proper solution to the> problem. > I didn't say it's better avoided, though of course I will avoid_any_ change if > I can. I said I have identified one drawback with doing it. Then I > have addressed > that drawback. So that's what I said. > > I am unaware of_other_ drawbacks. They might exist, but I am unaware of > them. Perhaps you are, and indeed you state they exist, but you refuse to > let me know about them. Or perhaps others know of them and will let me know. > In my long-running discussion with Dmitry they were not presented (again, > except for the one I identified). 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. To give an example of a subtle consequence: 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. And in the example above, the values are those that the lispref/objects.texi says we should not change (though it gives (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC the related discussions mentioned that modifying such values could lead to a segfault in some previous Emacs versions. Maybe not anymore, but it's still not a good idea.