bug#38614: 26.3; Info completions in reverse order

[Stefan Kangas <stefan@marxist.se>]

close 38614 28.1
thanks

Howard Melman <hmelman@gmail.com> 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