Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 19:15:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 20 15:15:26 2015
Received: from localhost ([127.0.0.1]:33840 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YkHAE-00060V-1K
for submit <at> 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 <monnier@HIDDEN>) id 1YkHAB-00060H-NI
for 20365 <at> 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 <monnier@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwvmw22d3ay.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
<jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
<jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN>
<jwviocqg9mt.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3otqBRNVjHoUXUZPxggNeejdamJMK570Tnmtk3xqHomyA@HIDDEN>
Date: Mon, 20 Apr 2015 15:14:55 -0400
In-Reply-To: <CAA01p3otqBRNVjHoUXUZPxggNeejdamJMK570Tnmtk3xqHomyA@HIDDEN>
(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@HIDDEN
X-Spam-Status: No
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 20365
Cc: 20365 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 14:53:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 20 10:53:06 2015 Received: from localhost ([127.0.0.1]:33707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1YkD4L-0006j6-Rn for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YkD4J-0006ic-HX for 20365 <at> debbugs.gnu.org; Mon, 20 Apr 2015 10:53:04 -0400 Received: by wiun10 with SMTP id n10so94801081wiu.1 for <20365 <at> 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: <jwviocqg9mt.fsf-monnier+emacsbugs@HIDDEN> References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> <jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN> <jwviocqg9mt.fsf-monnier+emacsbugs@HIDDEN> Date: Mon, 20 Apr 2015 16:52:57 +0200 Message-ID: <CAA01p3otqBRNVjHoUXUZPxggNeejdamJMK570Tnmtk3xqHomyA@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel <ohwoeowho@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) On Mon, Apr 20, 2015 at 4:38 PM, Stefan Monnier <monnier@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 14:39:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 20 10:39:18 2015
Received: from localhost ([127.0.0.1]:33690 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YkCqz-0006Op-N8
for submit <at> 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 <monnier@HIDDEN>) id 1YkCqx-0006Oh-In
for 20365 <at> 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 <monnier@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwviocqg9mt.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
<jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
<jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN>
Date: Mon, 20 Apr 2015 10:38:26 -0400
In-Reply-To: <CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN>
(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@HIDDEN
X-Spam-Status: No
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 20365
Cc: 20365 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 12:30:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 20 08:30:37 2015 Received: from localhost ([127.0.0.1]:33115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1YkAqT-0000NX-1C for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YkAqP-0000NI-V0 for 20365 <at> debbugs.gnu.org; Mon, 20 Apr 2015 08:30:34 -0400 Received: by wgin8 with SMTP id n8so176911436wgi.0 for <20365 <at> 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: <CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN> References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> <jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN> Date: Mon, 20 Apr 2015 14:30:27 +0200 Message-ID: <CAA01p3rKD37Mo1PDSnOEtvx=ShTVamgoDNVp+GCh83_QeW0UvQ@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel <ohwoeowho@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 08:38:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 20 04:38:23 2015 Received: from localhost ([127.0.0.1]:32995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Yk7Di-0008Tx-L7 for submit <at> 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 <ohwoeowho@HIDDEN>) id 1Yk7Dg-0008Tb-HO for 20365 <at> debbugs.gnu.org; Mon, 20 Apr 2015 04:38:21 -0400 Received: by widdi4 with SMTP id di4so82446932wid.0 for <20365 <at> 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: <jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN> References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> <jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN> Date: Mon, 20 Apr 2015 10:38:14 +0200 Message-ID: <CAA01p3rfJgkq9DSbktgU9yfgugokGWXa6wrCRrQ13zrwdTeMhQ@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel <ohwoeowho@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) On Mon, Apr 20, 2015 at 4:29 AM, Stefan Monnier <monnier@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 20 Apr 2015 02:29:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 22:29:04 2015
Received: from localhost ([127.0.0.1]:32830 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Yk1SJ-0007sZ-UU
for submit <at> 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 <monnier@HIDDEN>) id 1Yk1SH-0007sA-Lg
for 20365 <at> 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 <monnier@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwvzj63mtcp.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
<jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
Date: Sun, 19 Apr 2015 22:29:00 -0400
In-Reply-To: <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
(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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 17:12:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 13:12:51 2015 Received: from localhost ([127.0.0.1]:60862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Yjsm2-0001hz-Kb for submit <at> 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 <raaahh@HIDDEN>) id 1Yjsm0-0001hn-L8 for 20365 <at> debbugs.gnu.org; Sun, 19 Apr 2015 13:12:49 -0400 Received: by widdi4 with SMTP id di4so73439363wid.0 for <20365 <at> 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@HIDDEN> Date: Sun, 19 Apr 2015 20:12:40 +0300 From: Dmitry Gutov <dgutov@HIDDEN> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Oleh Krehel <ohwoeowho@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> <5533DB54.8000000@HIDDEN> <CAA01p3qiH4SUbOXkAVtYnh7V4q9k7Q9RgOjAbof4dSWg=K1mOg@HIDDEN> In-Reply-To: <CAA01p3qiH4SUbOXkAVtYnh7V4q9k7Q9RgOjAbof4dSWg=K1mOg@HIDDEN> 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 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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.
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 17:00:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 13:00:57 2015 Received: from localhost ([127.0.0.1]:60844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1YjsaW-0001Pk-DO for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjsaT-0001PX-W1 for 20365 <at> debbugs.gnu.org; Sun, 19 Apr 2015 13:00:54 -0400 Received: by wiun10 with SMTP id n10so67560686wiu.1 for <20365 <at> 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@HIDDEN> References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> <5533DB54.8000000@HIDDEN> Date: Sun, 19 Apr 2015 19:00:48 +0200 Message-ID: <CAA01p3qiH4SUbOXkAVtYnh7V4q9k7Q9RgOjAbof4dSWg=K1mOg@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel <ohwoeowho@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: Stefan Monnier <monnier@HIDDEN>, 20365 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) On Sun, Apr 19, 2015 at 6:44 PM, Dmitry Gutov <dgutov@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 16:44:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 12:44:14 2015 Received: from localhost ([127.0.0.1]:60835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1YjsKL-00010h-Vg for submit <at> 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 <raaahh@HIDDEN>) id 1YjsKK-00010U-M5 for 20365 <at> debbugs.gnu.org; Sun, 19 Apr 2015 12:44:13 -0400 Received: by wiax7 with SMTP id x7so66664481wia.0 for <20365 <at> 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@HIDDEN> Date: Sun, 19 Apr 2015 19:44:04 +0300 From: Dmitry Gutov <dgutov@HIDDEN> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Oleh Krehel <ohwoeowho@HIDDEN>, Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> In-Reply-To: <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> 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 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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.
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 14:44:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 10:44:02 2015
Received: from localhost ([127.0.0.1]:60802 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjqS1-0006eD-TF
for submit <at> 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 <drew.adams@HIDDEN>) id 1YjqRz-0006dm-BT
for 20365 <at> 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 <drew.adams@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>, Stefan Monnier
<monnier@HIDDEN>
Subject: RE: bug#20365: 24.5; all-completions returns duplicates for
Info-read-node-name-1
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
<jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
In-Reply-To: <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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)
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 11:53:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 19 07:53:23 2015 Received: from localhost ([127.0.0.1]:60465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1Yjnmt-0002Yk-2P for submit <at> 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 <ohwoeowho@HIDDEN>) id 1Yjnmq-0002YV-HO for 20365 <at> debbugs.gnu.org; Sun, 19 Apr 2015 07:53:21 -0400 Received: by wiun10 with SMTP id n10so63109298wiu.1 for <20365 <at> 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: <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> References: <87egnhfmcd.fsf@HIDDEN> <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN> <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN> <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN> Date: Sun, 19 Apr 2015 13:53:14 +0200 Message-ID: <CAA01p3ozqEygTNsmWMDwvcYSnJKCQSqJ8dKnSTZJuvmierPUTA@HIDDEN> Subject: Re: bug#20365: 24.5; all-completions returns duplicates for Info-read-node-name-1 From: Oleh Krehel <ohwoeowho@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20365 Cc: 20365 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 02:04:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 22:04:59 2015
Received: from localhost ([127.0.0.1]:60323 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjebS-0002Qt-Va
for submit <at> 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 <monnier@HIDDEN>) id 1YjebQ-0002Qk-HY
for 20365 <at> 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 <monnier@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwvsibwrimf.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
Date: Sat, 18 Apr 2015 22:04:54 -0400
In-Reply-To: <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
(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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
"(<file>)", 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 19 Apr 2015 01:50:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 21:50:50 2015
Received: from localhost ([127.0.0.1]:60315 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjeNm-00025e-6n
for submit <at> 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 <monnier@HIDDEN>) id 1YjeNj-00025T-5J
for 20365 <at> 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 <monnier@HIDDEN>
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwvy4lorimu.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
<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 <ohwoeowho@HIDDEN>, 20365 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 23:40:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 19:40:21 2015
Received: from localhost ([127.0.0.1]:60273 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjcLU-0007WG-US
for submit <at> 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 <drew.adams@HIDDEN>) id 1YjcLT-0007W2-Hb
for 20365 <at> 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 <drew.adams@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Oleh Krehel
<ohwoeowho@HIDDEN>
Subject: RE: bug#20365: 24.5; all-completions returns duplicates for
Info-read-node-name-1
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
In-Reply-To: <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 17:49:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 13:49:53 2015
Received: from localhost ([127.0.0.1]:60157 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjWsL-0003Nd-0x
for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjWsI-0003NP-FA
for 20365 <at> debbugs.gnu.org; Sat, 18 Apr 2015 13:49:51 -0400
Received: by wiun10 with SMTP id n10so50971311wiu.1
for <20365 <at> 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: <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
<jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
Date: Sat, 18 Apr 2015 19:49:44 +0200
Message-ID: <CAA01p3pUajf5XNSg2W5xThmUHVA3ETVJktCYNRpPCfyKOsxwmg@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
From: Oleh Krehel <ohwoeowho@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 20365
Cc: 20365 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
On Sat, Apr 18, 2015 at 7:41 PM, Stefan Monnier
<monnier@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at 20365) by debbugs.gnu.org; 18 Apr 2015 17:41:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 13:41:23 2015
Received: from localhost ([127.0.0.1]:60149 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjWk6-0003Bl-ST
for submit <at> 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 <monnier@HIDDEN>) id 1YjWk4-0003BX-8p
for 20365 <at> 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 <monnier@HIDDEN>
To: Oleh Krehel <ohwoeowho@HIDDEN>
Subject: Re: bug#20365: 24.5;
all-completions returns duplicates for Info-read-node-name-1
Message-ID: <jwvr3rhs5pu.fsf-monnier+emacsbugs@HIDDEN>
References: <87egnhfmcd.fsf@HIDDEN>
Date: Sat, 18 Apr 2015 13:41:17 -0400
In-Reply-To: <87egnhfmcd.fsf@HIDDEN> (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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 18 Apr 2015 16:17:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 18 12:17:00 2015
Received: from localhost ([127.0.0.1]:60125 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1YjVQR-0008Gt-NQ
for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjVQO-0008Gf-VC
for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjVQJ-00027P-09
for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjVQI-00027D-TQ
for submit <at> 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 <ohwoeowho@HIDDEN>) id 1YjVQI-0005ue-20
for bug-gnu-emacs@HIDDEN; Sat, 18 Apr 2015 12:16:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <ohwoeowho@HIDDEN>) id 1YjVQE-00026Z-S1
for bug-gnu-emacs@HIDDEN; 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 <ohwoeowho@HIDDEN>) id 1YjVQE-00026M-Kf
for bug-gnu-emacs@HIDDEN; Sat, 18 Apr 2015 12:16:46 -0400
Received: by widdi4 with SMTP id di4so49605506wid.0
for <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Sat, 18 Apr 2015 09:16:45 -0700 (PDT)
From: Oleh Krehel <ohwoeowho@HIDDEN>
To: bug-gnu-emacs@HIDDEN
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@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?
Oleh Krehel <ohwoeowho@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#20365; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.