From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 12:17:00 2015 Received: (at submit) by debbugs.gnu.org; 18 Apr 2015 16:17:00 +0000 Received: from localhost ([127.0.0.1]:60125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjVQR-0008Gt-NQ for submit@debbugs.gnu.org; Sat, 18 Apr 2015 12:16:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33978) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjVQO-0008Gf-VC for submit@debbugs.gnu.org; Sat, 18 Apr 2015 12:16:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjVQJ-00027P-09 for submit@debbugs.gnu.org; Sat, 18 Apr 2015 12:16:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:40680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjVQI-00027D-TQ for submit@debbugs.gnu.org; Sat, 18 Apr 2015 12:16:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjVQI-0005ue-20 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 12:16:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjVQE-00026Z-S1 for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 12:16:50 -0400 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:37796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjVQE-00026M-Kf for bug-gnu-emacs@gnu.org; Sat, 18 Apr 2015 12:16:46 -0400 Received: by widdi4 with SMTP id di4so49605506wid.0 for ; Sat, 18 Apr 2015 09:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type; bh=bFjRKVx3ZINAkBPWANTRQSsbRHy0328TzkCWM4eEtco=; b=mM+wQM5tOHCHq/NqM9NGVMoyNBBQgHLzUVogK+kMPuZZZCoyfheQy2WuDWo844qO7R LXgbDDHBlH1bpbLL2z1YL/iUNkFyr64bMktWOb3e6fyBemPXykxJ9vDwklUaAXi3Js7G 0UoVuDXAikyMD91HxPbHE/JP5Ipw71iFMu9mEBEqOgL6KIYOO5Drna4/g6ibLRON1Oay GhVuLs12S1RUQ6mhoKHGZJv7X3gsAgZHRzritoj0PPQ2cVszmbOKoRWBWJY7Kc650K+O cqwUe4IMTy7gL2YVvRXmMXhUHFQof9dCNdTLFFHvHvPib8Ot67eqKYyxMLLfjdXEF8f/ MYVQ== X-Received: by 10.194.237.34 with SMTP id uz2mr15368570wjc.157.1429373806042; Sat, 18 Apr 2015 09:16:46 -0700 (PDT) Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id e2sm7506696wij.5.2015.04.18.09.16.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 18 Apr 2015 09:16:45 -0700 (PDT) From: Oleh Krehel To: bug-gnu-emacs@gnu.org Subject: 24.5; all-completions returns duplicates for Info-read-node-name-1 Date: Sat, 18 Apr 2015 18:11:14 +0200 Message-ID: <87egnhfmcd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) To reproduce, eval this in the top *info* directory: (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". Finally, if one of the elements of `all-completions' is passed, it still doesn't work. I'm guessing that it expects "(org)" instead of "org", but then why not offer these on the completion list? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 13:41:23 2015 Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 17:41:23 +0000 Received: from localhost ([127.0.0.1]:60149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjWk6-0003Bl-ST for submit@debbugs.gnu.org; Sat, 18 Apr 2015 13:41:23 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46204) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjWk4-0003BX-8p for 20365@debbugs.gnu.org; Sat, 18 Apr 2015 13:41:21 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3IHfH3B032549; Sat, 18 Apr 2015 13:41:18 -0400 Received: by pastel.home (Postfix, from userid 20848) id C0CFB13BD; Sat, 18 Apr 2015 13:41:17 -0400 (EDT) From: Stefan Monnier To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> Date: Sat, 18 Apr 2015 13:41:17 -0400 In-Reply-To: <87egnhfmcd.fsf@gmail.com> (Oleh Krehel's message of "Sat, 18 Apr 2015 18:11:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5280=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5280> : inlines <2752> : streams <1424625> : uri <1910011> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) 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. > (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". 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. > Finally, if one of the elements of `all-completions' is passed, it still > doesn't work. What does "is passed" mean here? What does "doesn't work" mean here? > I'm guessing that it expects "(org)" instead of "org", but > then why not offer these on the completion list? What is "it"? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 13:49:53 2015 Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 17:49:53 +0000 Received: from localhost ([127.0.0.1]:60157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjWsL-0003Nd-0x for submit@debbugs.gnu.org; Sat, 18 Apr 2015 13:49:53 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37952) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjWsI-0003NP-FA for 20365@debbugs.gnu.org; Sat, 18 Apr 2015 13:49:51 -0400 Received: by wiun10 with SMTP id n10so50971311wiu.1 for <20365@debbugs.gnu.org>; Sat, 18 Apr 2015 10:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rPW9hjqclxhmC5o3D7KjiuxZ3MUrB159Tnnw/tk+f8=; b=iZvbow0PwTBuXSo35jOSR2aYm/riidy64ZN53sw9enayBkCPYyzrmrUEHH1mJIEOCm DY98ffnffsdJikGV8BbKmQ/40jB7wmygiuaiRyyl3tm1UMroytcarwKgmv9YUrSRHoKV oMeiuz5n9e2ulOjQgBxykar7FOtNixG+2gbPdPkEsT+1VbWK0lLH6M40gg7h0T9t/5GH 6TfUroRPJHv4XGBUfhgpgGmP35/Hd27jNDOGqCeVUdswSJWzqGZLVjakeLdSXBxV/qlO tfauyPSvVUF2c6cRRksHX16WsuKikV6ACDTOZzfbvCnZEdfCGvTp8UydsXytVVFA5QnY 3Waw== MIME-Version: 1.0 X-Received: by 10.194.161.193 with SMTP id xu1mr3991301wjb.48.1429379384756; Sat, 18 Apr 2015 10:49:44 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Sat, 18 Apr 2015 10:49:44 -0700 (PDT) In-Reply-To: References: <87egnhfmcd.fsf@gmail.com> Date: Sat, 18 Apr 2015 19:49:44 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Sat, Apr 18, 2015 at 7:41 PM, Stefan Monnier wrote: > 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. > >> (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". > > 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. > >> Finally, if one of the elements of `all-completions' is passed, it still >> doesn't work. > > What does "is passed" mean here? What does "doesn't work" mean here? > >> I'm guessing that it expects "(org)" instead of "org", but >> then why not offer these on the completion list? > > What is "it"? What I think is happening there is that Info calls `completing-read-function' and ultimately gives it (through all-completions) a list like '("org" "emacs"...). And then it expects the answer to be in the form "(org)" or "(emacs)". Which I think is strange. I've pushed recently this hack to `ivy-read', which makes it work for Info: ((eq collection 'Info-read-node-name-1) (if (equal Info-current-file "dir") (setq collection (mapcar (lambda (x) (format "(%s)" x)) (cl-delete-duplicates (all-completions "(" collection predicate) :test 'equal))) (setq collection (all-completions "" collection predicate)))) This is quite ugly to go to such lengths to deal with just one completion case. Oleh From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 19:40:21 2015 Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 23:40:22 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <2c99be72-92a2-4e33-84fc-5ce168624af2@default> Date: Sat, 18 Apr 2015 16:40:03 -0700 (PDT) From: Drew Adams To: Stefan Monnier , Oleh Krehel Subject: RE: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@gmail.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 21:50:50 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 01:50:50 +0000 Received: from localhost ([127.0.0.1]:60315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjeNm-00025e-6n for submit@debbugs.gnu.org; Sat, 18 Apr 2015 21:50:50 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:48727) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjeNj-00025T-5J for 20365@debbugs.gnu.org; Sat, 18 Apr 2015 21:50:48 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3J1oigp027239; Sat, 18 Apr 2015 21:50:45 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9EF892488; Sat, 18 Apr 2015 21:50:44 -0400 (EDT) From: Stefan Monnier To: Drew Adams Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> <2c99be72-92a2-4e33-84fc-5ce168624af2@default> Date: Sat, 18 Apr 2015 21:50:44 -0400 In-Reply-To: <2c99be72-92a2-4e33-84fc-5ce168624af2@default> (Drew Adams's message of "Sat, 18 Apr 2015 16:40:03 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5280=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5280> : inlines <2752> : streams <1424809> : uri <1910240> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20365 Cc: Oleh Krehel , 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > 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. Yes. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 18 22:04:59 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 02:04:59 +0000 Received: from localhost ([127.0.0.1]:60323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjebS-0002Qt-Va for submit@debbugs.gnu.org; Sat, 18 Apr 2015 22:04:59 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:34291) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjebQ-0002Qk-HY for 20365@debbugs.gnu.org; Sat, 18 Apr 2015 22:04:57 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3J24sBU028811; Sat, 18 Apr 2015 22:04:55 -0400 Received: by pastel.home (Postfix, from userid 20848) id B48BE2488; Sat, 18 Apr 2015 22:04:54 -0400 (EDT) From: Stefan Monnier To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> Date: Sat, 18 Apr 2015 22:04:54 -0400 In-Reply-To: (Oleh Krehel's message of "Sat, 18 Apr 2015 19:49:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5280=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5280> : inlines <2752> : streams <1424815> : uri <1910248> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > What I think is happening there is that Info calls > `completing-read-function' and ultimately gives it (through > all-completions) a list like '("org" "emacs"...). And then it expects > the answer to be in the form "(org)" or "(emacs)". Which I think is > strange. IIUC the problem is as follows: the completion-table used by "g" in Info-mode lets you complete node names in the current file or lets you complete file names (which are placed within parens), but the completion table itself does not add those parens [ A long standing missing feature here is that it doesn't know how to complete a node name after the "()", even though it's a very much valid input to provide. ] Your ivy-mode generally wants to have a list of strings as candidates and wants those strings to be valid return values, whereas the way completion tables are defined there is no guarantee that you can get that kind of info from the completion table. We could change the Info-mode completion table so as to include the closing paren in the output of `all-completions' (and probably include the opening paren as well, in that case). Note also that on my system "g (ema TAB" includes things like "emacs23/" where "(emacs23/)" is not a valid element (since emacs-23 is a directorym which is complete in steps, just as in C-x C-f). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 07:53:23 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 11:53:23 +0000 Received: from localhost ([127.0.0.1]:60465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjnmt-0002Yk-2P for submit@debbugs.gnu.org; Sun, 19 Apr 2015 07:53:23 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:38614) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjnmq-0002YV-HO for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 07:53:21 -0400 Received: by wiun10 with SMTP id n10so63109298wiu.1 for <20365@debbugs.gnu.org>; Sun, 19 Apr 2015 04:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dbjzf8Ps0vt+SxHWI5h37nnBHm8V1fdJ7yAmlakFBcI=; b=UUtbvg7FBd+xND4tP1fsRZR2T1Hr/6mbqOfY+5ZRn6t9rmuL6OfW7Yggd8CoEFuUMO 57VF7YUK2Vk8uUm7fcBCMJNsJqElHGxpb+Xjk6nzlzN38FVb/NiboC/habFKXNS/jcy5 WCvUBJhTYoDzuPNBZNs/RbI7WJeeNmVveKptx+tgDXxWD38oUHcj4Kd62jU5iW0TzBV7 JRUjeXjgaQo5hHvbq7NVXCuIEJrzqUfZw7LVdbidPAfqCYYFwdtdxpljSbiPLfP2v/mF k2yHddASrvSw8QWFXHXWbsIBuxhvJr6xB2gh9ZqYUXivZ4j7PEIPztzFRntBoRvPVHXu 1S7w== MIME-Version: 1.0 X-Received: by 10.194.161.193 with SMTP id xu1mr9490371wjb.48.1429444394807; Sun, 19 Apr 2015 04:53:14 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Sun, 19 Apr 2015 04:53:14 -0700 (PDT) In-Reply-To: References: <87egnhfmcd.fsf@gmail.com> Date: Sun, 19 Apr 2015 13:53:14 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > We could change the Info-mode completion table so as to include the > closing paren in the output of `all-completions' (and probably include > the opening paren as well, in that case). Note also that on my system > "g (ema TAB" includes things like "emacs23/" where "(emacs23/)" is not > a valid element (since emacs-23 is a directorym which is complete in > steps, just as in C-x C-f). That would be fine. It just makes sense for any element of what `all-completions' returns to be a valid answer. About the duplicate entries, I think it should be the responsibility of the caller to remove the duplicates. Here's my line of thought: a completion function is expected to have an O(N) complexity, where N is the amount of candidates. Removing duplicates is O(N^2) at worst, and O(NlogN) at best. So the completion function should not attempt to remove the duplicates. It's doesn't affect the performance when I do it for 1000 candidates, but when it's 20k (`describe-function') it can have an impact. The point is that the collection passed to the completion function can be very large, and all but O(N) algorithms should be avoided. On the other hand, the caller knows exactly the type of data that it's passing and may be able to remove the duplicates in an efficient way. Oleh From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 10:44:02 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 14:44:02 +0000 Received: from localhost ([127.0.0.1]:60802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjqS1-0006eD-TF for submit@debbugs.gnu.org; Sun, 19 Apr 2015 10:44:02 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:20975) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjqRz-0006dm-BT for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 10:44:00 -0400 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 t3JEhpMk020727 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Apr 2015 14:43:52 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3JEhp43002945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Apr 2015 14:43:51 GMT 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 t3JEhoii010882; Sun, 19 Apr 2015 14:43:50 GMT MIME-Version: 1.0 Message-ID: <132790ef-aecc-4c38-912b-facfc988abcb@default> Date: Sun, 19 Apr 2015 07:43:43 -0700 (PDT) From: Drew Adams To: Oleh Krehel , Stefan Monnier Subject: RE: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@gmail.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > It just makes sense for any element of what > `all-completions' returns to be a valid answer. Interesting point of view. Sounds familiar... ;-) http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D1085 > About the duplicate entries, I think it should be the responsibility > of the caller to remove the duplicates. Here's my line of thought: > a completion function is expected to have an O(N) complexity, where N > is the amount of candidates. Removing duplicates is O(N^2) at worst, > and O(NlogN) at best. So the completion function should not attempt to > remove the duplicates. It's doesn't affect the performance when I do > it for 1000 candidates, but when it's 20k (`describe-function') it > can have an impact. >=20 > The point is that the collection passed to the completion function > can be very large, and all but O(N) algorithms should be avoided. On > the other hand, the caller knows exactly the type of data that it's > passing and may be able to remove the duplicates in an efficient > way. FWIW - I agree that the calling code should control duplicate removal. (Definitely, `all-completions' should not do that.) But it can make sense to allow the calling program to optionally "reach inside `completing-read'" to do its duplicate removal. In Icicles, the caller can cause `completing-read' itself to remove duplicates by binding global variable `icicle-transform-function'. Because `completing-read' does some processing (e.g. sorting) after computation of the candidates, this filter promotion into `completing-read' can save some time. It can also give users dynamic control over the candidates to be matched (the completion domain). The value of variable `icicle-transform-function' is a function used to transform the list of completion candidates. Users can toggle such transforming on/off using `C-$' during completion. The most common use, by far, of `icicle-transform-function' is to bind it to a remove-duplicates function. Other uses include switching to a particular subset of candidates, against which user input is then matched. For example, using `C-$' with `icicle-apropos-value' toggles filtering the domain of initial candidates according to the prefix argument, as follows: * no prefix arg: only user options (+ values) * < 0: only commands (+ definitions) * > 0: only faces (+ plists) * =3D 0: only options (+ values), commands (+ defs), faces (+ plists) From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 12:44:14 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 16:44:14 +0000 Received: from localhost ([127.0.0.1]:60835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjsKL-00010h-Vg for submit@debbugs.gnu.org; Sun, 19 Apr 2015 12:44:14 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:33406) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjsKK-00010U-M5 for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 12:44:13 -0400 Received: by wiax7 with SMTP id x7so66664481wia.0 for <20365@debbugs.gnu.org>; Sun, 19 Apr 2015 09:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G/8LSwS/GtaYUiG8RXG0RjJPAk24tWXLRXmeibl/qbw=; b=Od9K7DUd4TJX8Di5cZMRWDW5/0gacjg3BOhGHcCxDVMKxe/PAq5iAf730vToMktIJV EXhjNAJgj5hhG07/CbEqIWtfsoT6qtAj5jkTyxeUe4Ra+r0pqRyjy6LG0qVsrWRK+iuB pUk9uVH1RL9oD1S7Zzb/pdCXpXXmHlUZmZJdETAK90L+SII44Jj7SwCahSjOlrb6/k5P Sum0vkoWrOAwXycRinNc62Y8E7hO22PrQgrJNyGW654Bpf3/IBWyWWI7qMqODGgV7EjA zGlLFXkhma4GaEckUp9wJzKaxJJLISwjIIKYVHFuJYVzEAFGhXPf1GAofnIfiJc4SWqI Ai+w== X-Received: by 10.194.61.133 with SMTP id p5mr24140355wjr.132.1429461846945; Sun, 19 Apr 2015 09:44:06 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ub1sm23635497wjc.43.2015.04.19.09.44.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 09:44:06 -0700 (PDT) Message-ID: <5533DB54.8000000@yandex.ru> Date: Sun, 19 Apr 2015 19:44:04 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Oleh Krehel , Stefan Monnier Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 02:53 PM, Oleh Krehel wrote: > About the duplicate entries, I think it should be the responsibility > of the caller to remove the duplicates. That could have been a decent argument if we're discussing a new API, and not an already widely-used one. > Here's my line of thought: a > completion function is expected to have an O(N) complexity, where N is > the amount of candidates. Removing duplicates is O(N^2) at worst, and > O(NlogN) at best. O(NlogN) is closer to the truth: First, you copy - O(N), then sort - O(NlogN), then call `delete-consecutive-dups' (linear time). > So the completion function should not attempt to > remove the duplicates. It's doesn't affect the performance when I do > it for 1000 candidates, but when it's 20k (`describe-function') it can > have an impact. Even on a decently-sized collection (38K), this takes only 80ms: (delete-consecutive-dups (sort (all-completions "" obarray) #'string<)) That's not terrible. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 13:00:57 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 17:00:57 +0000 Received: from localhost ([127.0.0.1]:60844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjsaW-0001Pk-DO for submit@debbugs.gnu.org; Sun, 19 Apr 2015 13:00:56 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:38529) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjsaT-0001PX-W1 for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 13:00:54 -0400 Received: by wiun10 with SMTP id n10so67560686wiu.1 for <20365@debbugs.gnu.org>; Sun, 19 Apr 2015 10:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TlgfO+vGBT5bIb1LadftsD4Dcm/POmnXB1hyLzbh7iM=; b=jCE8iVaJ4F1zo32+XCr/snmgX9fNIevv+lihTsmel9/DgGIDB8SPUdeJUOaSwd0N0o mK448mXi9qs0bZANWMwiMM7sQ7L5lyDiU2bwCbay/uBl8Rc/vocuZiL2F9+CCp+h/9ql xX4OV4s1ZSoH3VF8L/aqX+4eVPlnVkME3AsEhzec0mMr2QEDcemxG9hfPXESSdSvHyq7 b5sOM0mgnN6MYKtNaNEcnwqsvt+d/LIhgHFdvKb3iZAzSBfeDAbyAvUVP/8OxixM3lg9 gVUpY56hwIO5oZ4uoSBaYZIofZ2QnopfxUiMENOS7DcPhnBHj+PgST+ITsNx69sDrcHM BSWQ== MIME-Version: 1.0 X-Received: by 10.194.143.20 with SMTP id sa20mr22803429wjb.16.1429462848194; Sun, 19 Apr 2015 10:00:48 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Sun, 19 Apr 2015 10:00:48 -0700 (PDT) In-Reply-To: <5533DB54.8000000@yandex.ru> References: <87egnhfmcd.fsf@gmail.com> <5533DB54.8000000@yandex.ru> Date: Sun, 19 Apr 2015 19:00:48 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Dmitry Gutov Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: Stefan Monnier , 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Sun, Apr 19, 2015 at 6:44 PM, Dmitry Gutov wrote: > That could have been a decent argument if we're discussing a new API, and > not an already widely-used one. No problem: no completion package will complain if you don't pass it duplicates. Then it's just a matter of fixing the offening callers of completion one by one. >> Here's my line of thought: a >> completion function is expected to have an O(N) complexity, where N is >> the amount of candidates. Removing duplicates is O(N^2) at worst, and >> O(NlogN) at best. > > > O(NlogN) is closer to the truth: > > First, you copy - O(N), then sort - O(NlogN), then call > `delete-consecutive-dups' (linear time). > >> So the completion function should not attempt to >> remove the duplicates. It's doesn't affect the performance when I do >> it for 1000 candidates, but when it's 20k (`describe-function') it can >> have an impact. > > > Even on a decently-sized collection (38K), this takes only 80ms: > > (delete-consecutive-dups (sort (all-completions "" obarray) #'string<)) > > That's not terrible. Actually, 0.08 is a lot when you consider that I would call this after each key press (in case when the collection is a function, not for the static list). The sluggishness would be perceptible even for a relatively slow typist. And this is only the overhead, there's also actual computing to be done. There's no reason not to avoid this overhead cost. Oleh From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 13:12:51 2015 Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 17:12:51 +0000 Received: from localhost ([127.0.0.1]:60862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjsm2-0001hz-Kb for submit@debbugs.gnu.org; Sun, 19 Apr 2015 13:12:50 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:35629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjsm0-0001hn-L8 for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 13:12:49 -0400 Received: by widdi4 with SMTP id di4so73439363wid.0 for <20365@debbugs.gnu.org>; Sun, 19 Apr 2015 10:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ptKv/OTOhBjlqbvMpqd9pHv0cyx/1CUmNCH+Fq5Vp68=; b=D79ltPGNnHH4LJndRCb/UJ/zz5JHbO8Vy3dDkMbrhcMg3AEyyNdGn5UP0u5AC4SriW H8Z3taEDDXHeh4TEVMK4lkUbYSWUcc0A/Y8Cn9M5nu/ICk1iPRJuWnDUujg3gCyqvPKU 9cgsqs0PtV6D7zofFShd++q2xAuoPatzZGli6FUHCxarG5h/kgRaKmTYqwahgqIKu35U jD+wyc9j/UwvXEi9PW/zjmClZN1SYcl2x5w0U6+2Nita+66Bca+2xhbJ2bcMi/gVHSJ6 y8/nizg5ckWfLdk0GMMZlOfBPaCPlix/DmMHtrb7LPXVYvfxhGdpdujwOtIgIaKDxuJb ELOw== X-Received: by 10.194.77.180 with SMTP id t20mr24286242wjw.115.1429463563273; Sun, 19 Apr 2015 10:12:43 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gi17sm13541404wjc.8.2015.04.19.10.12.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 10:12:42 -0700 (PDT) Message-ID: <5533E208.9040106@yandex.ru> Date: Sun, 19 Apr 2015 20:12:40 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@gmail.com> <5533DB54.8000000@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 08:00 PM, Oleh Krehel wrote: > No problem: no completion package will complain if you don't pass it duplicates. > Then it's just a matter of fixing the offening callers of completion one by one. Good luck with that. > Actually, 0.08 is a lot when you consider that I would call this after > each key press (in case when the collection is a function, not for the > static list). The sluggishness would be perceptible even for a > relatively slow typist. And this is only the overhead, there's also > actual computing to be done. There's no reason not to avoid this > overhead cost. It's only 80ms as long as the list is unfiltered. Type one or two chars - and the already small delay disappears into nothing. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 19 22:29:04 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 02:29:04 +0000 Received: from localhost ([127.0.0.1]:32830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk1SJ-0007sZ-UU for submit@debbugs.gnu.org; Sun, 19 Apr 2015 22:29:04 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46366) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk1SH-0007sA-Lg for 20365@debbugs.gnu.org; Sun, 19 Apr 2015 22:29:02 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3K2T0Cn021100; Sun, 19 Apr 2015 22:29:00 -0400 Received: by pastel.home (Postfix, from userid 20848) id 2872C282C; Sun, 19 Apr 2015 22:29:00 -0400 (EDT) From: Stefan Monnier To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> Date: Sun, 19 Apr 2015 22:29:00 -0400 In-Reply-To: (Oleh Krehel's message of "Sun, 19 Apr 2015 13:53:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5281=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5281> : inlines <2753> : streams <1425373> : uri <1910934> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > That would be fine. It just makes sense for any element of what > `all-completions' returns to be a valid answer. What's a valid answer? all-completions will happily return "share/" when completing on "/usr/s", even if you're looking for a .tex file rather than a directory and even if there's no "share/" in the current directory either. Yet, we don't want all-completions to return elements of the form "/home/monnier/private/package/emacs/trunk/lisp/" since that would result in a lot of redundancy that then needs to be found&removed. So, no, all-completions just doesn't always return "valid answers". Instead, it returns chunks of text that can added to some prefix (which you can find via `completion-boundaries'), the result of which should be a prefix of a valid answer. > About the duplicate entries, I think it should be the responsibility > of the caller to remove the duplicates. That's the case currently. The completion-table is called and the caller is the UI, and currently it's the UI's responsibility to remove the duplicates. > Here's my line of thought: a completion function is expected to have > an O(N) complexity, where N is the amount of candidates. Removing > duplicates is O(N^2) at worst, and O(NlogN) at best. Actually, with a hash-table it's pretty much down to O(N). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 20 04:38:23 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 08:38:23 +0000 Received: from localhost ([127.0.0.1]:32995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk7Di-0008Tx-L7 for submit@debbugs.gnu.org; Mon, 20 Apr 2015 04:38:23 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:37314) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk7Dg-0008Tb-HO for 20365@debbugs.gnu.org; Mon, 20 Apr 2015 04:38:21 -0400 Received: by widdi4 with SMTP id di4so82446932wid.0 for <20365@debbugs.gnu.org>; Mon, 20 Apr 2015 01:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z1H7buDyfc322rTjGFebUb5wdOLnxwt2zYw+4azy98I=; b=nspW+7pd2w0bDz/MsWKWfMr8MQwAETo48LMc0/2Ev0alNIcDwxvsEMX+25JuImfCkq ybcMO4qPOSNW8ZHmGl/20LkiurMiayoRpWZAuK9gUC4B4JVSPXCykqnHU62nsNA+tyad 7ZTL7nnn5eiCd+SPXW96Njk7wd0Hw7ERKa+bRri5vXf5nvMU5FMS8T+hkrNZlrDVKr2e 20oeOo55UTnszaKZTRL7R8llfmdc8oNPaYclDwtXbn9JlCzb8+/bvyO0703FpsNknNsS q3BoEtGUmDEBLVwMkWRGARWm0sWjxpINJML+Qz+R3FvLEdHRdSEgXcqOuuZSZP5tE6gt oR6A== MIME-Version: 1.0 X-Received: by 10.180.95.36 with SMTP id dh4mr23552819wib.82.1429519094773; Mon, 20 Apr 2015 01:38:14 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Mon, 20 Apr 2015 01:38:14 -0700 (PDT) In-Reply-To: References: <87egnhfmcd.fsf@gmail.com> Date: Mon, 20 Apr 2015 10:38:14 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, Apr 20, 2015 at 4:29 AM, Stefan Monnier wrote: >> That would be fine. It just makes sense for any element of what >> `all-completions' returns to be a valid answer. > > What's a valid answer? A valid answer is the one that doesn't lead to an error if `completing-read-function' returns it. Also, in my experience, having less callbacks leads to easier debugging. I've looked at the callbacks in `incomplete-mode': the completion function gets called like 3 times for a single input. > all-completions will happily return "share/" when completing on > "/usr/s", even if you're looking for a .tex file rather than a directory > and even if there's no "share/" in the current directory either. This would be good if there was a "share/" in the current directory. I'm fine with the concept of `all-completions' being able to return "infinite" candidates, but it would be nice if it obeyed some rules. For instance, ivy-mode can handle the file names being "infinte", because of the concept of directories being non-terminal completion nodes. This concept can be adapted to all compltetion types with "infinite" candidates. And there would be zero confusion: `all-completions' would immediately return a list of strings, some of them terminal nodes, some of them "directories". Then it only remains to provide a generic `file-directory-p' and we're done. > Yet, we don't want all-completions to return elements of the form > "/home/monnier/private/package/emacs/trunk/lisp/" since that would > result in a lot of redundancy that then needs to be found&removed. With a concept of "active directory" and "non-terminal" node this can be done. "active directory" would be a generic `default-directory', and "non-terminal" would be a generic predicate `file-directory-p'. > So, no, all-completions just doesn't always return "valid answers". > Instead, it returns chunks of text that can added to some prefix (which > you can find via `completion-boundaries'), the result of which should be > a prefix of a valid answer. We could have the cake and eat it too with my approach described above. >> About the duplicate entries, I think it should be the responsibility >> of the caller to remove the duplicates. > > That's the case currently. The completion-table is called and the > caller is the UI, and currently it's the UI's responsibility to remove > the duplicates. So Info returning duplicates is a bug that should be fixed? >> Here's my line of thought: a completion function is expected to have >> an O(N) complexity, where N is the amount of candidates. Removing >> duplicates is O(N^2) at worst, and O(NlogN) at best. > > Actually, with a hash-table it's pretty much down to O(N). Yeah, but we're not using that. And having no assumptions on the data, the hashing function would be the most basic one. Oleh From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 20 08:30:37 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 12:30:37 +0000 Received: from localhost ([127.0.0.1]:33115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkAqT-0000NX-1C for submit@debbugs.gnu.org; Mon, 20 Apr 2015 08:30:37 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:33130) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkAqP-0000NI-V0 for 20365@debbugs.gnu.org; Mon, 20 Apr 2015 08:30:34 -0400 Received: by wgin8 with SMTP id n8so176911436wgi.0 for <20365@debbugs.gnu.org>; Mon, 20 Apr 2015 05:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GMHpQKA3HNeYD0GWg71gF+KCYvZiQNs3C74+BqodLFI=; b=mtniYkyUJr1n+v9Dw3pkTRBRVq9PwEYXoM07Z/LBz68T0MLMIqa4Ch9ltzi/lHCIj3 6oAA8CyYQiN+BHYhjtLsSggH6E2AxLJjLdNRH4utpIzBtBXNbQHBIBH9D/z6m4f7CusS IrV0ZGxNxqqAmChF1huKjlKMc1Qu0HgYko9pxK0ytBxp7883hILGiitw1TyTCUrQi+Hx gO1hbpEiX5C+Op2eThX07ac0I1jVV0M0IGadZLHFMyf8NU2zftz0UgMfez/iRuieYqcG o/yjd4lqE9EJxCgHZQQ7hxdZWCv3ESUgzppCVAnWqdQLzbhZdalR8c3IEY457rS7gsvb hKyg== MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr24475188wib.22.1429533027974; Mon, 20 Apr 2015 05:30:27 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Mon, 20 Apr 2015 05:30:27 -0700 (PDT) In-Reply-To: References: <87egnhfmcd.fsf@gmail.com> Date: Mon, 20 Apr 2015 14:30:27 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Please check the "fix-info-dups" brach with a fix. This patch removes the duplicates and generally simplifies the completion of Info files. Oleh From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 20 10:39:18 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 14:39:18 +0000 Received: from localhost ([127.0.0.1]:33690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkCqz-0006Op-N8 for submit@debbugs.gnu.org; Mon, 20 Apr 2015 10:39:18 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:37232) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkCqx-0006Oh-In for 20365@debbugs.gnu.org; Mon, 20 Apr 2015 10:39:16 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 560EC85FBF; Mon, 20 Apr 2015 10:38:55 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 1009E1E5B8B; Mon, 20 Apr 2015 10:38:27 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id E02FCB40DC; Mon, 20 Apr 2015 10:38:26 -0400 (EDT) From: Stefan Monnier To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> Date: Mon, 20 Apr 2015 10:38:26 -0400 In-Reply-To: (Oleh Krehel's message of "Mon, 20 Apr 2015 10:38:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > nodes. This concept can be adapted to all compltetion types with > "infinite" candidates. And there would be zero confusion: > `all-completions' would immediately return a list of strings, some of > them terminal nodes, some of them "directories". Then it only remains > to provide a generic `file-directory-p' and we're done. Yes, that's also what I was thinking. Basically, if all-completions returns something which requires further input, then this something should include the "terminating char" which makes completion-boundaries change (which is how to detect that your candidate list is out-of-date because the input has "moved to another directory"). >> That's the case currently. The completion-table is called and the >> caller is the UI, and currently it's the UI's responsibility to remove >> the duplicates. > So Info returning duplicates is a bug that should be fixed? Our UI already does remove duplicates (not in info.el, of course, since our UI is in minibuffer.el). >>> Here's my line of thought: a completion function is expected to have >>> an O(N) complexity, where N is the amount of candidates. Removing >>> duplicates is O(N^2) at worst, and O(NlogN) at best. >> Actually, with a hash-table it's pretty much down to O(N). > Yeah, but we're not using that. Not sure who's "we", here. But the point is that if the performance of delete-dups becomes a problem, it can be improved. > And having no assumptions on the data, the hashing function would be > the most basic one. I don't think that should make much difference: (make-hash-table :test #'equal) should work just fine. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 20 10:53:06 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 14:53:06 +0000 Received: from localhost ([127.0.0.1]:33707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkD4L-0006j6-Rn for submit@debbugs.gnu.org; Mon, 20 Apr 2015 10:53:06 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:37951) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkD4J-0006ic-HX for 20365@debbugs.gnu.org; Mon, 20 Apr 2015 10:53:04 -0400 Received: by wiun10 with SMTP id n10so94801081wiu.1 for <20365@debbugs.gnu.org>; Mon, 20 Apr 2015 07:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MGRn7niOn+7jIbssleQ9Bf7fZogdDDv3CbI8ZnqX6Yg=; b=0KhcBg2HiOQVHVTFe8I6dSXqn3kZ+9m0sn+ULCWXDTKUUL1ixYEet7oID7ljw4qdNK dMLDoUgd/3Nm8eu40gTzcbLUO39nsk2jcKhqVUrC6o3EcH1DNwVgj/Y926cL2oWg7Ze/ erpbQna+eQ2KzgA8Z/Eqa0eEYwOQtR2JSKe13Mr2tRKtyoFxNxjaktSm3Q7BTIthgHXX altRmXBw5sqC/SBih1dw9xABczYdPo0tXhxh+J1eCzLlxVFep1GYEpDDpDYIQU3kA4gv lvcajxi/SNSRwaC6TeNNXQ68QcGvoiw87pUYbU/q0AjXxI4Bt2Rsk2Vcx+v5Eq7RH6n/ 42HA== MIME-Version: 1.0 X-Received: by 10.194.59.4 with SMTP id v4mr32362920wjq.54.1429541577693; Mon, 20 Apr 2015 07:52:57 -0700 (PDT) Received: by 10.27.215.21 with HTTP; Mon, 20 Apr 2015 07:52:57 -0700 (PDT) In-Reply-To: References: <87egnhfmcd.fsf@gmail.com> Date: Mon, 20 Apr 2015 16:52:57 +0200 Message-ID: Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, Apr 20, 2015 at 4:38 PM, Stefan Monnier wrote: >> nodes. This concept can be adapted to all compltetion types with >> "infinite" candidates. And there would be zero confusion: >> `all-completions' would immediately return a list of strings, some of >> them terminal nodes, some of them "directories". Then it only remains >> to provide a generic `file-directory-p' and we're done. > > Yes, that's also what I was thinking. Basically, if all-completions > returns something which requires further input, then this something > should include the "terminating char" which makes completion-boundaries > change (which is how to detect that your candidate list is out-of-date > because the input has "moved to another directory"). I'm not fully familiar with the concept of completion-boundaries, but I have a feeling that I won't like it, specifically the multiple callback passes for a response to a single completion input change. Is the concept of completion-boundaries irreplaceable, could it maybe be replaced by a notion of navigating a tree (just like navigating a file system, with terminal and non-terminal nodes). Which Emacs features use the completion-boundaries concept? >>> That's the case currently. The completion-table is called and the >>> caller is the UI, and currently it's the UI's responsibility to remove >>> the duplicates. >> So Info returning duplicates is a bug that should be fixed? > > Our UI already does remove duplicates (not in info.el, of course, since > our UI is in minibuffer.el). I've added a fix to Info in any case. Can you please look at it in the fix-info-dups branch? >>>> Here's my line of thought: a completion function is expected to have >>>> an O(N) complexity, where N is the amount of candidates. Removing >>>> duplicates is O(N^2) at worst, and O(NlogN) at best. >>> Actually, with a hash-table it's pretty much down to O(N). >> Yeah, but we're not using that. > > Not sure who's "we", here. But the point is that if the performance of > delete-dups becomes a problem, it can be improved. We are the happy Emacs users. >> And having no assumptions on the data, the hashing function would be >> the most basic one. > > I don't think that should make much difference: (make-hash-table :test #'equal) > should work just fine. OK, that's good to keep in mind. But even better is to avoid placing the overhead on the UI, be it minibuffer.el or ivy.el or whatever. Oleh From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 20 15:15:26 2015 Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 19:15:26 +0000 Received: from localhost ([127.0.0.1]:33840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHAE-00060V-1K for submit@debbugs.gnu.org; Mon, 20 Apr 2015 15:15:26 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:32772) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHAB-00060H-NI for 20365@debbugs.gnu.org; Mon, 20 Apr 2015 15:15:24 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 413AB85FA8; Mon, 20 Apr 2015 15:15:23 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id D4AC41E5B8C; Mon, 20 Apr 2015 15:14:55 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id BBC50B40DC; Mon, 20 Apr 2015 15:14:55 -0400 (EDT) From: Stefan Monnier To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 Message-ID: References: <87egnhfmcd.fsf@gmail.com> Date: Mon, 20 Apr 2015 15:14:55 -0400 In-Reply-To: (Oleh Krehel's message of "Mon, 20 Apr 2015 16:52:57 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20365 Cc: 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I'm not fully familiar with the concept of completion-boundaries, but I I know, but if you intend to support a completion UI that works with existing completion-tables, you're going to have to become at least somewhat acquainted to it. > Is the concept of completion-boundaries irreplaceable, could it maybe be > replaced by a notion of navigating a tree (just like navigating a file > system, with terminal and non-terminal nodes). Which Emacs features use > the completion-boundaries concept? All the "special" examples of completion I showed (plus file name completion). > OK, that's good to keep in mind. But even better is to avoid placing the > overhead on the UI, be it minibuffer.el or ivy.el or whatever. Many completion tables are made by combining other completion tables. Doing the delete-dups at every step is going to be more code and more runtime work than doing it once at the end in the UI. So the UI will have to do it. Completion-tables can also do it if they want, but it should not be necessary for correctness. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 17 06:51:32 2022 Received: (at 20365) by debbugs.gnu.org; 17 Apr 2022 10:51:32 +0000 Received: from localhost ([127.0.0.1]:35047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ng2VA-0003hV-3d for submit@debbugs.gnu.org; Sun, 17 Apr 2022 06:51:32 -0400 Received: from quimby.gnus.org ([95.216.78.240]:41496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ng2V8-0003hI-77 for 20365@debbugs.gnu.org; Sun, 17 Apr 2022 06:51:30 -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=ohKcbe/u/K+p53LS97x36doNoKWRFA5bNK0v/RGdAlI=; b=DfwgtPTV9OQcr8BCf5KL2kAyL/ ElLHD1Zmltws03ohv0z8wXaQjc2pAFM8ZsGngv6i+Z1CpDVYpfqDuUlp+/xZNDzzzMFPnwgbeMgR4 xrGm5x9pOq3mobp+ixU0AE3W8D08CVyQVJueduQasK5Pr7mAI7BdAGitX27OM8Hb70mU=; 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 1ng2Uw-00046h-UX; Sun, 17 Apr 2022 12:51:23 +0200 From: Lars Ingebrigtsen To: Oleh Krehel Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@gmail.com> Date: Sun, 17 Apr 2022 12:51:17 +0200 In-Reply-To: (Oleh Krehel's message of "Mon, 20 Apr 2015 14:30:27 +0200") Message-ID: <87lew4aspm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Oleh Krehel writes: > Please check the "fix-info-dups" brach with a fix. This patch removes > the duplicates and generally simplifies the completion of Info files. I've now applied that patch to Emacs 29 (with some changes), and I think that fixes the reported problem here, so I'm closing the bug report. (The discussion then went on to more general issues of dup [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20365 Cc: Stefan Monnier , 20365@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Oleh Krehel writes: > Please check the "fix-info-dups" brach with a fix. This patch removes > the duplicates and generally simplifies the completion of Info files. I've now applied that patch to Emacs 29 (with some changes), and I think that fixes the reported problem here, so I'm closing the bug report. (The discussion then went on to more general issues of duplicates in completions.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 17 06:51:36 2022 Received: (at control) by debbugs.gnu.org; 17 Apr 2022 10:51:36 +0000 Received: from localhost ([127.0.0.1]:35050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ng2VE-0003hm-BT for submit@debbugs.gnu.org; Sun, 17 Apr 2022 06:51:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:41510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ng2VC-0003hN-Up for control@debbugs.gnu.org; Sun, 17 Apr 2022 06:51:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sNktS6IDx5v2P6Rj11bq+cWbF4+G/7aLu0E+S9IZV/s=; b=GyksCY9vTA3Qu8df+QAweLGTFE mKX3+9FuNBVKV17PdmXeeaEYsI6F4xMqjJrM5Ui9tUTc1eyH/8wXHvIO1fuRoVkU/iG4NoxqA+Tz1 RKRnkEokBRsC6wWnsLk3JtSb3MoRK7MAyP+HAXn6pWS2luBW8en1Ugnbw7/aUtuxJ7vw=; 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 1ng2V5-00046q-1i for control@debbugs.gnu.org; Sun, 17 Apr 2022 12:51:29 +0200 Date: Sun, 17 Apr 2022 12:51:26 +0200 Message-Id: <87k0boaspd.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20365 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 20365 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 20365 29.1 quit From unknown Thu Aug 14 22:23:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 May 2022 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator