From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates Date: Mon, 2 May 2022 11:00:18 +0200 Message-ID: <8eda03fd-975d-26f7-efe5-c0193a83d75a@daniel-mendler.de> References: <4d1b8687-20f2-137a-2739-7bba28828991@daniel-mendler.de> <87wnf5mpt4.fsf@gnus.org> <87k0b5duzh.fsf@gnus.org> <8735htdrmt.fsf@gnus.org> <87wnf49ww8.fsf@gnus.org> 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="6185"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55205@debbugs.gnu.org To: Lars Ingebrigtsen , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 02 11:02:00 2022 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 1nlRwO-0001OA-DV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 11:02:00 +0200 Original-Received: from localhost ([::1]:51550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlRwM-00043p-0p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 05:01:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlRvW-0003nM-Io for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 05:01:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40903) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlRvT-0001Vs-5T for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 05:01:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlRvT-0003zO-3y for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 05:01:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2022 09:01:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55205 X-GNU-PR-Package: emacs Original-Received: via spool by 55205-submit@debbugs.gnu.org id=B55205.165148202813096 (code B ref 55205); Mon, 02 May 2022 09:01:03 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 2 May 2022 09:00:28 +0000 Original-Received: from localhost ([127.0.0.1]:34799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlRut-0003Op-RU for submit@debbugs.gnu.org; Mon, 02 May 2022 05:00:28 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:36093 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlRur-0003HF-Ht for 55205@debbugs.gnu.org; Mon, 02 May 2022 05:00:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+wjSYK6bidScQHHmy8lEQ1UbMXB3TpegVgBpgNpQd68=; b=swr/IPHesIvmTEFCkrBeHVhdC9 FY3TInMQO/6ZVEf8vmZBb0sBxS154XTZ4Z3cdUCKdCLxSIZh0pEB+XmR42zEcFAha6savmmXarWmm eSfJczDMbcZ9ptISD2eWNCR89IXN6fonbnsvGDKi2IdhrKh+HQ4Q+GfhbjVxR1UXedi8=; Content-Language: en-US In-Reply-To: <87wnf49ww8.fsf@gnus.org> 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:231238 Archived-At: On 5/2/22 10:11, Lars Ingebrigtsen wrote: > Stefan Monnier writes: > >> I'm a strong proponent of "different completions should be selectable by >> different strings", for the kinds of reasons exposed by Daniel: it makes >> it possible to use more UI styles than just selection (and it interacts >> better with other things like elimination of duplicates). > > If we have completions that are textually different, then that's no > problem, of course. But requiring the callers to construct strings that > differ in artificial ways seems less than optimal. I argue that the strings should not differ in artifical ways. If you want to select from different candidates which are actually different in some ways. For example movies with the same name from the same year certainly have different directors and different actors. The user can then match against the name of the director when searching for the movie. If the candidates would be truly "more equal", such that the disambiguation suffix would be truly artificial, then why would you distinguish the candidates in the first place? >>> If I remember correctly, I ended up copying most of the completion >>> machinery into the package just to avoid the stripping. >> >> We should fix the code so it's not necessary. > > Which brings me back to my original question. 😀 Why are we stripping > text properties? Is this to fix some bug or something? > > I.e., if we add an interface to allow completion to not strip text > properties, is that going to lead to bugs? I mentioned this in my other mail. The text properties don't necessarily materialize in the first place, because it is just textual input by the user. If a UI wants to enforce that text properties are returned it could do so by performing a lookup in the final step and by setting minibuffer-allow-text-properties. By stripping the text property we ensure that the result is normalized and uniform across all scenarios. As I mentioned before, text properties are only meaningful for REQUIRE-MATCH non-nil and also not for the "null completion" (empty string). Btw, I consider the "null completion" a design mistake which should be corrected. If REQUIRE-MATCH is non-nil, no null completion should be allowed. If the caller of completing-read truly wants the null completion they can either modify the test-completion action of the programmable completion table or pass the empty string as DEFAULT argument to completing-read. Daniel