bug#54175: 27.2; Info-follow-reference completions in reverse order

[Howard Melman]

To follow up on this from Feb.  Here's a summary of
what's been discussed.  My original report:

> This is the same issue as in bug#38614 which was about
> Info-complete-menu-item, but this is about
> Info-follow-reference.  I hope it will also be fixed.
>
> Info-follow-reference calls completing-read with a list of
> candidates found in the node.  It scans the node from top to
> bottom pushing references onto a completions list.  The list
> ends up being in the reverse order of position in the node.
> For the default completion mechanism this isn't a problem,
> but with a completion package like fido or ivy which
> immediately displays the list of candidates, this order
> isn't particularly useful.
>
> My use case is browsing an info manual, going to a new node
> via n, so my point is near the top of the node.  I see I
> want to follow the first reference and type f and I'm
> presented with a list of completion candidates. The first
> candidate is from the bottom of the node, it's not even
> visible on my screen.  If the list was in the order as found
> in the mode I could just type RET, but now I have to type to
> complete or beforehand position point at the reference so
> that it will be used as a default.
>
> I suggest adding something like the following in
> Info-follow-reference just after the while loop that builds
> completions:
>
>      (setq completions (nreverse completions))
>

Eli argued that this would put a burden on users who stick
with the default completion system.  I showed that his example
degenerate case had no meaningful performance impact.

He also asked why is this order more meaningful.  It seems
obvious to me that the order the references appear in the
text is more meaningful than the reverse of that order.  And I
showed a common use case of visiting a page and wanting
to follow one of the first references without having to move point,
particularly if the node fits on one page.

Eli proposed some different order could be more useful.  I said "I
proposed an easy-to-understand one line fix with negligible
performance impact similar to a previously accepted fix; if someone
wants to fix it with a rewrite of the function I don't object."
Additionally, I point out that this change doesn't affect that if
point is on a reference the default is still that reference.

I also pointed out:

> There is code in Info-menu-update "stolen from
> `Info-follow-reference'" that builds the dynamic submenu of
> References.  That currently shows references, in the menu in the
> same reverse order.  It would be nice if those were in some sensible
> order; either alphabetical or as found in the node seem more
> reasonable than what's there now.

I think the order of a menu is more clearly a bug than of a
completion table, but I think both should be fixed. My
preference would be that the order in a menu be the order of
references found in the text and that Info-follow-reference
candidates use the same order.  I think alphabetical is also
reasonable for this menu and could be different from
Info-follow-reference, but I don't see how it's useful for
either to be in the reverse order as found in the text.

I still think the proposed one line fix (applied in both
places) is the easiest and least risky change.

-- 

Howard