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: Mon, 02 May 2022 10:11:35 +0200 Message-ID: <87wnf49ww8.fsf@gnus.org> References: <4d1b8687-20f2-137a-2739-7bba28828991@daniel-mendler.de> <87wnf5mpt4.fsf@gnus.org> <87k0b5duzh.fsf@gnus.org> <8735htdrmt.fsf@gnus.org> 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="1150"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Daniel Mendler , 55205@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 02 10:12:41 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 1nlRAf-000AeB-05 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 10:12:41 +0200 Original-Received: from localhost ([::1]:42600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlRAd-0001jx-KG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 May 2022 04:12:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlRA2-0001h3-EB for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 04:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40824) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlRA2-0002vA-56 for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 04:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlRA1-0005lM-U2 for bug-gnu-emacs@gnu.org; Mon, 02 May 2022 04:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 May 2022 08:12: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.165147910922134 (code B ref 55205); Mon, 02 May 2022 08:12:01 +0000 Original-Received: (at 55205) by debbugs.gnu.org; 2 May 2022 08:11:49 +0000 Original-Received: from localhost ([127.0.0.1]:34721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlR9p-0005kw-CY for submit@debbugs.gnu.org; Mon, 02 May 2022 04:11:49 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:39974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlR9n-0005ki-Qw for 55205@debbugs.gnu.org; Mon, 02 May 2022 04:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From: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=LpLdDyb9PR+9GWLnN30BYQEAln4w5+0FGs3xRKsuaUI=; b=Ay3bl9Y8Xpgpo+lUG25q+QHDs6 aw54taV4DnQSbXcOvJ6QWR3fBPzKye8KoT5bPva9sUa6mgpbJyJuGIYoUYku70pbDelY5LbqWylfC qDQeiJfaxzVV2Jq5D1g2avTcHKJWOVpDOMzOwgzMDPAo1E3cV4hCHLjJECOLzTRgXp8E=; 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 1nlR9d-0006o2-3V; Mon, 02 May 2022 10:11:39 +0200 X-Now-Playing: Bogdan Raczynski's _Mixes_: "Mix 7" In-Reply-To: (Stefan Monnier's message of "Mon, 02 May 2022 02:31:05 -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:231230 Archived-At: 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. > But FWIW, that is not a reason to force throwing away the text > properties (IOW the act of stripping the text properties is not > a feature of the code). > > E.g. I'd recommend you always include the movie's unique ID in the > completions, probably covered/hidden by the movie's poster (so the ugly > ID doesn't show up). And when the user selects that entry it would make > a lot of sense to keep displaying the poster. I think that's what people normally do in these circumstances, but it's a pretty confusing interface. The completions show up looking identical, but with hidden text that you can complete with. >> 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 str= ipping 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? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no