[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38614: 26.3; Info completions in reverse order
From: |
Howard Melman |
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@marxist.se> wrote:
>
> Howard Melman <hmelman@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