Subject: bug#38614: 26.3; Info completions in reverse order

From: Howard Melman <[email-masked]>
Date: Tue, 25 Aug 2020 19:38:11 -0400

> On Aug 25, 2020, at 7:09 PM, Stefan Kangas <[email-masked]> wrote:
> 
> Howard Melman <[email-masked]> 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