From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates Date: Tue, 03 May 2022 12:13:36 +0200 Message-ID: <87k0b2zzxr.fsf@gnus.org> 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14181"; 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: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 03 12:14:12 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 1nlpXo-0003Sy-AH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 12:14:12 +0200 Original-Received: from localhost ([::1]:44276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlpXm-0001RV-Tg for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 06:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlpXe-0001Q8-NT for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 06:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlpXe-00006k-Cj for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 06:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlpXe-0006rA-4w for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 06:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 May 2022 10:14: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.165157283426335 (code B ref 55205); Tue, 03 May 2022 10:14:02 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 3 May 2022 10:13:54 +0000 Original-Received: from localhost ([127.0.0.1]:38725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlpXW-0006qg-Ac for submit@debbugs.gnu.org; Tue, 03 May 2022 06:13:54 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:53690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlpXT-0006qT-VN for 55205@debbugs.gnu.org; Tue, 03 May 2022 06:13:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=wPN+cMEzKbs9eXYImjYN1YiVfgnrhDoJuUyGQK9bifs=; b=bxwgL7VTBG+UUBh07nk9zrnhWE QF+UaVt/4gRdC3fMKiAa9Q3JmJPdR2AdWguNWhe9yh0lG2Gs8pWJk27h4emThzgljl76Hh43WOSNC 6v7EZOzpXN6hKURr+50bly3j5Yf9+eHZu9y5VBAzh24RbT+ROCc11wQv27Stt+milAB0=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nlpXJ-00045O-Lp; Tue, 03 May 2022 12:13:44 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUsVXEwZ49Hd5qK a1QLEBJBUVpSha7///93llwQAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YFAwoGKLjk+AsAAAG5SURB VDjLbZPNbqQwDMcdBD3HiN6Jd8W51WrvU9W5pyvyAEVq3v8R1k4IYYbxJcK//P0ZAMTQwjMzOCLi U/ALnxERkIJLPERyGRSNsY+CHaBetVMQUP05lpEjhhgFjA4PA7A+rp8x9gFyrY1MPpiYtXhv6w2R v+ACLDNi/34FrytLkqChtjvQs9qXgrRJI1TxxBw95JYobZToqJn5809paaSURFW7nDz/LQDHRYjG yiJbQB6MguRavW87GNMZSJJbmRulR+CLYimATp2UqT0C6UR2NfABaqxX5g+BFWyHQoA5gZZcgNbM l6oU9BnQIsNqyQcBOmGZFS15WnWFzGsGOnRN7hrgApSQBbwA9ZO1+SAk2e0O9Nt1zlCxnj/6mpxo BgPZ7cb+5n4fob4BnO12xY36A8iThfkRiN/J5pvCl7ogZwBCO79sCqZarjRuRYbjHBbxL+W+VyCp LVoDgwb74UMxWjA6jw6CgPUA+m8ZfWAmQLdUQVylgfzrORtjR6XSXQE0i2+GIZh7MBIML5tciN0y rw1QmmVTcwQI36b5GXSveh+Gf9vAJ9DRRlDAT38GwVEBEGOL5P1/7KuiJdq5fh8AAAAldEVYdGRh dGU6Y3JlYXRlADIwMjItMDUtMDNUMTA6MDY6NDArMDA6MDAh1QnxAAAAJXRFWHRkYXRlOm1vZGlm eQAyMDIyLTA1LTAzVDEwOjA2OjQwKzAwOjAwUIixTQAAAABJRU5ErkJggg== X-Now-Playing: Depeche Mode's _Construction Time Again_: "Pipeline" In-Reply-To: (Stefan Monnier's message of "Mon, 02 May 2022 08:23:57 -0400") 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:231313 Archived-At: 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. :-) In my use case, the stringly representation is not the identity of the selection. > 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. > 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. >> 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. I was being vague, because I don't know how we'd specify "don't strip the text properties". Probably like how we specify affixation functions and all the rest. But I still have no idea why we're stripping text properties in the first place, so could you please explain that? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no