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

[Eli Zaretskii <eliz@gnu.org>]

> From: Howard Melman <hmelman@gmail.com>
> Date: Sat, 26 Feb 2022 19:17:21 -0500
> 
> 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))

I must say that I'm uneasy with such changes, which punish every user
of Info because some optional completion facility out there would like
that.  It sounds wrong.  Why shouldn't we expect from those optional
completion facilities to do this if and when they need?