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: Mon, 02 May 2022 08:23:57 -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> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12605"; 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 Mon May 02 14:25:28 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 1nlV7H-00038K-9m for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 14:25:27 +0200 Original-Received: from localhost ([::1]:55378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlV7F-0003jD-MP for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 08:25:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlV6s-0003in-4R for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 08:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41163) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlV6r-0006oA-R7 for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 08:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlV6r-0001DE-NR for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 08:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2022 12:25:01 +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.16514942484589 (code B ref 55205); Mon, 02 May 2022 12:25:01 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 2 May 2022 12:24:08 +0000 Original-Received: from localhost ([127.0.0.1]:35060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlV60-0001Bw-DS for submit@debbugs.gnu.org; Mon, 02 May 2022 08:24:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlV5y-0001BN-4F for 55205@debbugs.gnu.org; Mon, 02 May 2022 08:24:06 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B84B610028F; Mon, 2 May 2022 08:24:00 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D8987100121; Mon, 2 May 2022 08:23:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651494238; bh=FTMvhq8fqUOFjY3KVBJQ6zuOBzDutsYIraHT/ZwOgpc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=F8F/yRsfMd25ZewjsnxgQ2cjrbVD8hHcGk0Q9PyAVYkLj6p1dCdBvH0/4YQllxX9I ok4BH5+3jdnDf1yT1dATboEYnBXA14GbH52UvWvK8GoOY9eXQ8icrReCFh73eq2Hn6 siFqEmRUQYhZ5UklDvtkUbymX7fOQcSqQ2iitLqKefr51Pw/INv6ieakWkgL1kKvmX j7EF5446Ou/v4f99BQSIzCp07hqpMoaZtGmBLIh6yNDxMcArxOkfcTxoKPyyqmzjF6 +UT3Qm6QDHAqCC+KLUs0xzrUFN74k4EGgpvCpdQW0kq7Vf4vVSpWJJzMF5SILccjuZ cQ/n4PAnwdFRQ== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 84D841201A4; Mon, 2 May 2022 08:23:58 -0400 (EDT) In-Reply-To: <87wnf49ww8.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 02 May 2022 10:11:35 +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:231256 Archived-At: Lars Ingebrigtsen [2022-05-02 10:11:35] 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. 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. 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)) The `movie-id` could be derived from the poster itself if needed. I can't see why you'd find that to be a problem. You can also move the movie to an "annotation" and make movie names unique by adding a number, something like: (defun movie-make-unique (movies) "MOVIES is a list of (MOVIE . IMAGE). Return a new list of (MOVIE . IMAGE) where every MOVIE is unique." (let ((ht (make-hash-table :test 'equal))) (mapcar (lambda (m) (let* ((name (car m)) (old (gethash name ht)) (new (if (null old) m (unless (cdr old) (setf (caar old) (concat (car old) " (1)"= ))) (cons (format "%s (%d)" name (1+ (length ol= d))) (cdr m))))) (setf (gethash name ht) (cons new old)) new)) movies))) We could add such a function to `minibuffer.el`. >>> 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. =F0=9F=98=80 Why are we s= tripping > text properties? Is this to fix some bug or something? 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.e., if we add an interface to allow completion to not strip text > properties, is that going to lead to bugs? What do you mean by "interface"? You mean a UI or an API? For an API it would probably lead to this API being virtually unusable for some UIs. Stefan