From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: handling of completion table duplicates Date: Sun, 3 Apr 2016 08:55:48 -0700 (PDT) Message-ID: <0782d65f-084b-4aba-9813-83aa9a78e81b@default> References: <87h9fiewnf.fsf@acer.localhost.com> <87inzyzrpa.fsf@linux-m68k.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1459698991 28631 80.91.229.3 (3 Apr 2016 15:56:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 15:56:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ingo Lohmar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 03 17:56:19 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1amkNv-0001GO-JC for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 17:56:19 +0200 Original-Received: from localhost ([::1]:54008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkNs-0006bg-0v for ged-emacs-devel@m.gmane.org; Sun, 03 Apr 2016 11:56:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkNe-0006bJ-0h for emacs-devel@gnu.org; Sun, 03 Apr 2016 11:56:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amkNa-0004Iv-PF for emacs-devel@gnu.org; Sun, 03 Apr 2016 11:56:01 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amkNa-0004Il-GI for emacs-devel@gnu.org; Sun, 03 Apr 2016 11:55:58 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u33FtrwK012915 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Apr 2016 15:55:54 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u33Ftq81002961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Apr 2016 15:55:53 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u33FtoEX016179; Sun, 3 Apr 2016 15:55:51 GMT In-Reply-To: <87inzyzrpa.fsf@linux-m68k.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202634 Archived-At: > > I recently noticed that ivy-mode (at its very core a completing-read > > alternative, just like ido-completing-read is another one) does *not* > > eliminate duplicates from the collection it is passed, eg, in form of a > > plain list. (completing-read "Prompt: " '("a" "b" "c" "a" "d")) > > Both completing-read as well as ido-completing-read remove such > > duplicates, >=20 > all-completions doesn't. The removal is probably just a side effect > of the implementation. Yes. > > Is removing duplicates from the collection *expected* from completion > > functions, or is the caller of the function responsible for providing a > > collection without duplicates? >=20 > IMHO it's the resposibility of the caller to make sure the completion > table is useful. Yes. This question of duplicates has been discussed here before. http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00161.html IMO, `completing-read' too should not remove duplicates, by default. It should be possible to bind a variable around its call, to control whether it does. (No, the calling sequence should not be changed at this point.) One reason for not having it force duplicate removal is the question of what it means to be a "duplicate". That judgment should come only from the caller, not from `completing-read'. `completing-read' treats its completions only as plain strings for comparison purposes, including matching, sorting, and duplicate removal. (Symbol-name strings are compared, for symbol candidates.) But in fact, the raw completion candidates from argument COLLECTION can be arbitrarily rich, containing much more information - information that is ignored by the simple comparisons made now. A raw candidate can be any of the following (at least): * A cons (for an alist COLLECTION), and its cdr can be an arbitrary Lisp value. * A symbol, and its plist can be an arbitrary plist, with arbitrary Lisp values for the entries. * A string, and it can have arbitrary text properties, with arbitrary Lisp values. (And this applies also to the car of a cons raw candidate.) * A hash-table key, and it can have an arbitrary Lisp value as its associated value. IOW, `completing-read' can be passed candidates of arbitrary richness, but it starts by ignoring that richness, in effect reducing these raw candidates to simple strings. But there is sufficient generality here for callers of `completing-read' to retrieve a Lisp value associated with the plain-string candidate currently used by it. Candidate removal should be the privilege of the caller, not `completing-read'. The caller knows whether it might want to distinguish two strings that have the same text but different text properties; or two conses that have the same string car but different cdrs; etc. `completing-read' was designed long before there was any notion or use of cycling among candidates, and thus before any notion of a "current" candidate. Its design assumes that the only way to distinguish (choose) a candidate is to match an input string against a set of string candidates. Input is assumed to be by typing (versus yanking), so text properties are not considered for the input string. Simple string-vs-string comparison is the design. The fact that `completing-read' accepts a COLLECTION arg that might associate additional information with a string is a result only of providing for the convenient use of existing structures (alists, to start with). It does not try to make any use of that additional info. As soon as candidate cycling, for example, is introduced, there is another way for a user to distinguish a candidate besides the input string: the current cycling candidate. (Actually, even before cycling, mouse selection of a candidate also lets a user pick among "duplicates".) Of course, a user also needs some way to distinguish duplicates visually, in order to choose one (e.g., by cycling or mouse). This can come in various forms: annotation, display of additional info during cycling, etc. --- As one example, Icicles makes extensive use of the ability to distinguish "duplicate" candidates. I'm sure that other applications do too. In Icicle minor mode, `completing-read' is redefined to allow for, but not impose, duplicate removal. An Icicle user can use `C-$' (`icicle-toggle-transforming) to toggle whether and how the set of candidate completions is transformed initially. Typically, this transformation just removes duplicate candidates. Programmatically, a `completing-read' caller can remove duplicates by binding `icicle-transform-function' to `icicle-remove-duplicates'. "Sorting Candidates and Removing Duplicates": https://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates