From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Date: Sat, 18 Apr 2015 16:40:03 -0700 (PDT) Message-ID: <2c99be72-92a2-4e33-84fc-5ce168624af2@default> References: <87egnhfmcd.fsf@gmail.com> 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 1429400487 5289 80.91.229.3 (18 Apr 2015 23:41:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 23:41:27 +0000 (UTC) Cc: 20365@debbugs.gnu.org To: Stefan Monnier , Oleh Krehel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 19 01:41:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1YjcMJ-0004zb-Im for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 01:41:11 +0200 Original-Received: from localhost ([::1]:47142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjcMI-0005WL-L7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 18 Apr 2015 19:41:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjcMF-0005W4-63 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 19:41:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjcMB-00026u-05 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 19:41:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjcMA-00026m-T7 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 19:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YjcMA-0007XM-8x for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 19:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2015 23:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20365 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20365-submit@debbugs.gnu.org id=B20365.142940042228913 (code B ref 20365); Sat, 18 Apr 2015 23:41:02 +0000 Original-Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 23:40:22 +0000 Original-Received: from localhost ([127.0.0.1]:60273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjcLU-0007WG-US for submit@debbugs.gnu.org; Sat, 18 Apr 2015 19:40:21 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40990) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjcLT-0007W2-Hb for 20365@debbugs.gnu.org; Sat, 18 Apr 2015 19:40:20 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3INeCxF001046 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2015 23:40:12 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3INe99K026338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 18 Apr 2015 23:40:10 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3INe9f2008782; Sat, 18 Apr 2015 23:40:09 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101695 Archived-At: > Just a first comment: it's not considered incorrect for > `all-completions' to return a list with duplicate entries in it. > More specifically, it's considered the completion UI's job to remove > those duplicates. Yes, absolutely. > > (setq x (all-completions "(" 'Info-read-node-name-1)) > > x will contain many duplicates for each node, like "org" "org" > > "org" "org" "org.info.gz" "org" "org.info.gz" "org" "org.info.gz". >=20 > Maybe the way these entries are generated could be reviewed to try > and reduce the number of duplicates. And we could call `delete-dups' on > the result: while a completion-table shouldn't need to go out of its way > to reduce the number of duplicates (since the UI is supposed to handle > it anyway), it's probably good to avoid having such expected large > number of duplicates, indeed. Just to be sure - I hope you mean to do this only in `Info-read-node-name-1' or in the code that calls `completing-read' (or in a "completion UI"). I hope you don't mean to do any of that in `all-completions'. I'm guessing that this is what you mean. If my guess is correct, then you need not read any further, and thanks for confirming the guess. --- In case not, let me disagree that such things should be done in `all-completions' and similar functions or in `completing-read'. They should not delete duplicates. In my context, for instance, the completion candidates are often alist elements where the cdrs matter. Or they are strings that are `string=3D' but have different properties. The cdrs or the string properties matter to the code that calls `all-completions' or `completing-read'. The calling code reconstructs the alist element from the chosen candidate(s) (it provides access to the associated cdr information). It is important in such contexts to allow "duplicates", as defined from the point of view of comparing only the cars with `string=3D' (which is what `all-completions' does). Just because two completion candidate strings are equal does not mean that the alist elements of which they are the cars are equal. It should be entirely up to the caller to delete duplicates. It is trivial for it to do so, and logical that this be the place where that is done. Only the caller (or the "completion UI") knows whether duplicates make sense in the current context. `all-completions' & compagnie are building blocks (and coded in C, no less, so not tweakable in Lisp). It is not their job to either (a) filter out duplicates or (b) try not to produce duplicates. (a) is the job of their callers, which are the consumers of the candidates. (b) is the job of the COLLECTION function or other producer of the candidates. So please try to tackle any problem of duplicates in this particular use case by fiddling with `Info-read-node-name-1', and not by introducing a change in `all-completions' etc.