From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#38614: 26.3; Info completions in reverse order Date: Wed, 26 Aug 2020 16:20:38 -0700 Message-ID: References: <83mubt60an.fsf@gnu.org> <57154DCC-52F1-4B7A-BDB8-A3586E365C29@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31591"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38614@debbugs.gnu.org To: Howard Melman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 27 01:21:10 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kB4j7-00086T-Kr for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 Aug 2020 01:21:09 +0200 Original-Received: from localhost ([::1]:51044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kB4j6-00078p-AJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Aug 2020 19:21:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kB4j0-00078V-5K for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2020 19:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57775) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kB4iz-0008Lf-S2 for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2020 19:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kB4iz-0007DZ-Mr for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2020 19:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Aug 2020 23:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38614 X-GNU-PR-Package: emacs Original-Received: via spool by 38614-submit@debbugs.gnu.org id=B38614.159848404627711 (code B ref 38614); Wed, 26 Aug 2020 23:21:01 +0000 Original-Received: (at 38614) by debbugs.gnu.org; 26 Aug 2020 23:20:46 +0000 Original-Received: from localhost ([127.0.0.1]:41086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kB4ij-0007Cs-MB for submit@debbugs.gnu.org; Wed, 26 Aug 2020 19:20:45 -0400 Original-Received: from mail-yb1-f195.google.com ([209.85.219.195]:34185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kB4ii-0007CZ-HD for 38614@debbugs.gnu.org; Wed, 26 Aug 2020 19:20:44 -0400 Original-Received: by mail-yb1-f195.google.com with SMTP id u6so1917975ybf.1 for <38614@debbugs.gnu.org>; Wed, 26 Aug 2020 16:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=sq9sliMfyZ/Sa94SsfbNe8/Zfa6EeQVsY9iu3VbbyNo=; b=kEAabulKsw0CwbiGiE6P0nBbG6/8oh4aomnr97TgLeEDwTriy7eZWVGZsO3MMcP8g+ U9/kEO9+UGqVWg1skvh+WqVb242SGp66HFQHU7ZclCr9Xl3ZY7vWWpYAr6Dpdxx6G+Ro NCXjVl15wIej8jBKwg1VUXTnLcnIqU50RtvMYe5V8/gwNbvWDvkShLcetTZhLnVvxCJM ijUCDx7e6TPEF1SvOBI8W3GzXDtL7a8xk0zrc24BPEnMyk4O+RLeX53HwqX/ezhpgB7P JCa52afCgc/Hl2odYljYSJHBc82hADaQOZykZvPtQRqL+MfCzxCKhRjLc05ASEIcuc8L GqcQ== X-Gm-Message-State: AOAM531T4gmkA2qfOk5aP2H3rZXTigSkUn9UR7VCg1AaCAZugWvvFrlB ZdpczXmSdG5RKM0IlIsImTlGeyYvEHaqjfeRUwo= X-Google-Smtp-Source: ABdhPJwpqyARWVEmhZHio/HdJis8NgCwnNgHW4FI39TDOm7OOm2/R5cQv37WnDqljzpXeRUi8AT04MRYvpwNVDSV5QQ= X-Received: by 2002:a25:4ed7:: with SMTP id c206mr26033756ybb.129.1598484038926; Wed, 26 Aug 2020 16:20:38 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 26 Aug 2020 16:20:38 -0700 In-Reply-To: <57154DCC-52F1-4B7A-BDB8-A3586E365C29@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186485 Archived-At: close 38614 28.1 thanks Howard Melman writes: > While I don't particularly know ido code and only know a little of > ivy, I think understand what's happening here. Both ivy and standard > emacs facilities use the list of candidates passed to completing-read, > in this case that's code that's part of info-mode and not an ivy > function or an ido function. > > Ivy will show a list of candidates immediately, before you type any > input, and once you start typing input, will narrow and sort that list > of candidates (using some criteria). ido (or whatever emacs' default > is) AFAIU doesn't show candidates before you hit TAB and once you do, > it shows a sorted list of matching candidates. > > The bug here, is that the initial list, generated by info-mode code, > the one ivy shows and ido doesn't, returns the candidates in list in > the reverse order it found them in the buffer (unlike other places > that generate candidate lists). I agree, there's no requirement about > the order of the initial candidates list, but it would be reasonable > for the list, in this case, generated from an info page, to be in the > order they appear in the page, and while base emacs doesn't make use > of that order, ivy would (and possibly helm, I'm not sure). > > AFAIK users of the standard emacs facilities will see no functional > change by this. There's just the cost of the nreverse, which given > the number of menu entries in an info page should be negligible and in > some cases, like info indexes that are in alphabetical order > initially, this should be faster, because for a list already in > reverse alphabetical order, nreverse and sort could be faster than > just sort. Thanks for the explanation. I think your reasoning here makes sense. I made the change and tested the default, ido-mode, fido-mode and icomplete. I did not observe any regressions in terms of performance or sort order for any of them. In addition, I have also been bothered by this issue in the past using Ivy, and can confirm that the proposed fix solves the issue. So I have now made that change on the master branch (commit 5a1785d58a). If anyone notices any adverse effects from this change, feel free to revert it. I'm closing this bug report with this message. Best regards, Stefan Kangas