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

[Howard Melman <hmelman@gmail.com>]

On Feb 27, 2022, at 2:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> 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?

1. I understand your "who has the burden" argument but the cost of 
reversing a list of a handful of items is hardly punishment. And I 
explained my use case which for a user means fewer keystrokes
in a common case (visit the first reference without having to navigate
to it or type it's name) which seems far more meaningful than a 
negligible cost in other cases.

2. It's not unreasonable to expect a completion table to be in a meaningful 
order when there is one.  And there's no way for a completion package to
generate this order unless it assumes the candidates of this command are
in this reverse order, which isn't part of the contract.

3. Why should other completions facilities, some of which ship with emacs, 
be punished because the default one decides to not show any candidates
without first sorting them after someone hits TAB?

Howard