GNU bug report logs - #54175
27.2; Info-follow-reference completions in reverse order

Previous Next

Full log

Message #11 received at 54175 <at> debbugs.gnu.org (full text, mbox):

From: Howard Melman <hmelman <at> gmail.com>
To: 54175 <at> debbugs.gnu.org
Subject: Re: bug#54175: 27.2; Info-follow-reference completions in reverse
 order
Date: Sun, 27 Feb 2022 10:43:49 -0500

On Feb 27, 2022, at 2:17 AM, Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.