GNU bug report logs - #38614
26.3; Info completions in reverse order

Previous Next

Package: emacs;

Reported by: Howard Melman <hmelman <at> gmail.com>

Date: Sat, 14 Dec 2019 21:17:02 UTC

Severity: normal

Found in version 26.3

Fixed in version 28.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Howard Melman <hmelman <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 38614 <at> debbugs.gnu.org
Subject: bug#38614: 26.3; Info completions in reverse order
Date: Tue, 25 Aug 2020 19:38:11 -0400

> On Aug 25, 2020, at 7:09 PM, Stefan Kangas <stefan <at> marxist.se> wrote:
> 
> Howard Melman <hmelman <at> gmail.com> writes:
> 
>>>> When using ivy mode, Info-index shows me the list of
>>>> completions in reverse alphabetical order. Info-menu does too.
>>>> Both Info-index and Info-menu use completing-read with
>>>> Info-complete-menu-item as the collections argument. It
>>>> seems to generate the list in reverse order.
>>>> 
>>>> Sorry this isn't a formatted patch, but a one line fix solves it for me.
>>>> 
>>>> If after this line in Info-complete-menu-item:
>>>> 		    (setq completions (delete-dups completions))
>>>> I add this line:
>>>> 		    (setq completions (nreverse completions))
>>>> the index and menus are shown in alphabetical order.
> 
> Won't the proposed change:
> 
>  a) Not delete duplicates.

No, it adds a line, it doesn't replace it.  (Also note my correction of 3 Jan 2020 that puts the reverse just before the ";; Update the cache."

>  b) Reverse the list of completions for everyone else (ido, etc.)?

No, and I tried to explain it in a previous reply.

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.

Howard



This bug report was last modified 4 years and 272 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.