From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates Date: Tue, 03 May 2022 08:55:37 -0400 Message-ID: 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> <87k0b2zzxr.fsf@gnus.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27507"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Daniel Mendler , Eli Zaretskii , 55205@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 03 14:56:15 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 1nls4c-0006vg-Ke for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 14:56:14 +0200 Original-Received: from localhost ([::1]:38270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nls4b-0001It-2o for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 08:56:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50998) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nls4Q-0001Ik-QO for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 08:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nls4Q-0005ju-H4 for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 08:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nls4Q-0007J9-6u for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 08:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 May 2022 12:56:02 +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.165158254828072 (code B ref 55205); Tue, 03 May 2022 12:56:02 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 3 May 2022 12:55:48 +0000 Original-Received: from localhost ([127.0.0.1]:38938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nls4B-0007Ih-HM for submit@debbugs.gnu.org; Tue, 03 May 2022 08:55:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nls4A-0007IV-FI for 55205@debbugs.gnu.org; Tue, 03 May 2022 08:55:46 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BDD54441369; Tue, 3 May 2022 08:55:40 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 17E80440FB3; Tue, 3 May 2022 08:55:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651582539; bh=lRKsssHU7/rWk89NDs4Q4rBagkzPuBUpAUeWFBC4xHM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=LGuu/K9XTyHGogB9ognhwZ1EW1JNwVJwudCAX1icd5UEmat0ROFyTioAkJYB1Xxvf vZWfahuwFA7bc+iCivmYGWmw6AYdSDFs7lmRZueL4HTAO9UjZsnUqEwq3ovmdEH0aw HO5Ay2OC+/srKkRCF/RZyF1Az/wlAiUYF0a0g3Zn6XhgIzgGLPpli/Cp/5tQWh0ncr XtOsWGn4M0oJYJmY2ul6UP2KY5hBNHdWNV5JL/DGqf2GxQZuxB6ptCiU0dTMsG0lv8 CTE987eiMru1E6fzCjpS0GIyVqodr6aaPRioPDExQ0/UoOwU9Sm12zRt60uGBI7meF zKPmK9o4MMHvw== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B452F120312; Tue, 3 May 2022 08:55:38 -0400 (EDT) In-Reply-To: <87k0b2zzxr.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 03 May 2022 12:13:36 +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:231324 Archived-At: Lars Ingebrigtsen [2022-05-03 12:13:36] wrote: > Stefan Monnier writes: >> The strings used for completions are the "identity" of each completion. >> so if there are two distinct completions, they should have >> distinct strings. I don't see what's artificial about it. > > The "are" there is doing a lot of work here. :-) Yes, but that's the underlying design of the system. > In my use case, the stringly representation is not the identity of > the selection. And that's the core of your problem. >> Somehow the user (and the code) needs to be able to distinguish between >> the various identically named movies. You do that with a poster image >> and I'm suggesting that this poster image should be covering some >> "unique" identification information. I.e. something like: >> >> (concat movie-name (propertize movie-id 'display movie-poster)) > > And that is the artificiality of it. If you're on a web page listing > different items, and they have the same name, you don't see the web > designers putting made-up irrelevant characters into the link text -- > they keep the identifying stuff hidden in the links. I think this goes to the core of the difference between the web's design and Emacs's design, where we like to make everything reflected explicitly as text rather than hidden somewhere internal. It makes some things a bit more ugly sometimes, but it does tend to repay in the long run. >> The rest of the discussion made me realize that maybe I misunderstood >> your question. Are you talking about the stripping that takes places >> *during completion* (e.g. when clicking in *Completions*) or are you >> talking about the stripping that takes place just before returning the >> value of `completing-read`? Some other? > > I don't remember any more -- I only know that the text properties are > stripped at some point. Well, I think we should preserve the properties a much as possible on the way from the completion data to the actual completion place (typically the minibuffer) so as to preserve fonts, colors, images, etc when applicable. But w.r.t propagating text properties from the minibuffer's content to the returned value of `completing-read` I'm not sure that's a good idea, for the reason Daniel explained: it would encourage people to abuse them in the way you want to abuse the design, which would then make it unusable for some completion UIs. > But I still have no idea why we're stripping text properties in the > first place, so could you please explain that? It depends where. In `completion--replace` it's explained in the comment: ;; The properties on `newtext' include things like the ;; `completions-first-difference' face, which we don't want to ;; include upon insertion. -- Stefan