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: Sun, 01 May 2022 20:39:22 +0200 Message-ID: <8735htdrmt.fsf@gnus.org> References: <4d1b8687-20f2-137a-2739-7bba28828991@daniel-mendler.de> <87wnf5mpt4.fsf@gnus.org> <87k0b5duzh.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="35064"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Stefan Monnier , 55205@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 01 20:40: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 1nlEUP-0008v9-D7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 May 2022 20:40:13 +0200 Original-Received: from localhost ([::1]:51706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlEUO-0002v6-5p for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 May 2022 14:40:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlEUE-0002u4-Iz for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 14:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40286) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlEUE-0003dT-9l for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 14:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlEUE-0003xY-5u for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 14:40: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: Sun, 01 May 2022 18:40: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.165143037515182 (code B ref 55205); Sun, 01 May 2022 18:40:02 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 1 May 2022 18:39:35 +0000 Original-Received: from localhost ([127.0.0.1]:34183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlETn-0003wn-JC for submit@debbugs.gnu.org; Sun, 01 May 2022 14:39:35 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:33914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlETm-0003wY-S8 for 55205@debbugs.gnu.org; Sun, 01 May 2022 14:39:35 -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=9lgyMhpAiHdX7V7nDQhhmv1lr3S9f5RqtDkYjIWIvjk=; b=XB+yMw+cDWdQkX39ZmZgrMQ7WS voq3u9Yrl+e8lLZ3izHG/p+vvRMIc0XrQ6rA9pzSN7ClwpM+OGSAVYrQFDZag3cL/0fOhiN3+qubA mn57WwDr3wuVNbM9HK0rmHp9y2nsljluUjKFpugZBccZg2ijBE+MQyXkVOnUNtCkezsY=; 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 1nlETb-0000BC-KX; Sun, 01 May 2022 20:39:25 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAAAXNSR0IArs4c6QAAAAlQTFRF NjEurZ+U////zOWjqgAAAAFiS0dEAmYLfGQAAAAJcEhZcwAACxIAAAsSAdLdfvwAAAAHdElNRQfm BQESFTabOL65AAAAuklEQVQoz3WQSw7EIAiGIZE9k7T3YZK610Tvf5UB1Mq86KZf/wdWAICz+xSw 6QFwKuIwlRaV9p3pIUO/2gYMCT2P2d4rwC6o7CChbO4ZK98h/VXgEcGkLAt007Wh3mvcVyACTRTN CBroyQVWBIdtQbLqMoHtFsq2UQTMu4Cu0Ea9btvZRdKtNGFagI1HkU/WxaIxk0meekIZNtYHygS9 Lr2W/a/aL+yZJe7BT7g/EAdI0XiESDpKLBB6AZJ2PakqBaeNAAAAJXRFWHRkYXRlOmNyZWF0ZQAy MDIyLTA1LTAxVDE4OjIxOjU0KzAwOjAwfiN5ygAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wNS0w MVQxODoyMTo1NCswMDowMA9+wXYAAAA4dEVYdGljYzpjb3B5cmlnaHQAQ29weXJpZ2h0IChjKSAx OTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55+Vd5NwAAACF0RVh0aWNjOmRlc2NyaXB0aW9uAHNS R0IgSUVDNjE5NjYtMi4xV63aRwAAACZ0RVh0aWNjOm1hbnVmYWN0dXJlcgBJRUMgaHR0cDovL3d3 dy5pZWMuY2gcfwBMAAAAN3RFWHRpY2M6bW9kZWwASUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBj b2xvdXIgc3BhY2UgLSBzUkdCRFNIqQAAAABJRU5ErkJggg== X-Now-Playing: Let's Eat Grandma's _Two Ribbons_: "Insect Loop" In-Reply-To: (Daniel Mendler's message of "Sun, 1 May 2022 20:27:41 +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:231192 Archived-At: Daniel Mendler writes: > However when completing a string in the minibuffer, the completed string > can also be typed by the user and as such won't have the text properties > attached in the first place. The completion UI would then have to lookup > the input string in the list of propertized candidate strings. Of course > this makes only sense for REQUIRE-MATCH non-nil. Ah, yes, I was thinking about the REQUIRE-MATCH case. > One motivation for text property preservation is the disambiguation of > equal strings. I argue that equal candidate strings are not a good idea > since the user has no way to distinguish them TAB completing. I've got an imdb interface where I choose among different movies (some with the same name) by putting the movie poster in the completion string to disambiguate. That's the first place I ran into the problem, years ago (and it seems like people keep trying to do things like that, and then giving up). If I remember correctly, I ended up copying most of the completion machinery into the package just to avoid the stripping. (It's a somewhat marginal problem, since it's seldom there's several movies with the same name in the same year, but it happens. But you could imagine the same issue when completing, say, names in an org, and displaying pics of the people to disambiguate.) > It boils down to the question if we treat completion as step-by-step > text completion (by pressing TAB) or as a selection process of a > candidate. Due to the way these different UIs behave, selection vs > completion is a gray zone. Hm, yes. > For unique candidate strings and REQUIRE-MATCH non-nil, looking up > metadata in a hash table or an alist after the return of > completing-read is only a small inconvenience. Yes, but if the strings are identical (except for the text properties), then that's not really an option. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no