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

Previous Next

Package: emacs;

Reported by: Howard Melman <hmelman <at> gmail.com>

Date: Sun, 27 Feb 2022 00:18:01 UTC

Severity: minor

Found in version 27.2

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Howard Melman <hmelman <at> gmail.com>
To: 54175 <at> debbugs.gnu.org
Subject: bug#54175: 27.2; Info-follow-reference completions in reverse order
Date: Sun, 27 Feb 2022 12:50:38 -0500
On Feb 27, 2022, at 12:31 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Howard Melman <hmelman <at> gmail.com>
>> Date: Sun, 27 Feb 2022 12:18:49 -0500
>> 
>>>> I believe I explained this.  It is the order they are found in the node. It means 
>>>> the offered candidates appear to me in the order I see them in the
>>>> node.
>>> 
>>> But if your position is near the end of the buffer, the first
>>> cross-reference in the node will also be the one that's the farthest.
>>> I'm not sure I understand the utility of such an order.
>> 
>> It doesn't help in all cases.  If you're positioned near the end of the node
>> then you might be positioned near the reference and get it as the default.
>> But when visiting a node you start at the top, and many nodes fit entirely
>> on one screen, so it's a more common case that it will help (again for a
>> imperceptible cost).  It's certainly a more intuitive order than what is returned
>> now.
> 
> I don't think I agree.  I could understand if the request was to order
> them starting from the current position, or to sort them by their
> distance from the current position, but starting from the node
> beginning sounds as arbitrary as starting from the end.
> 
> In any case, instead of sorting or reversing, an alternative could be
> to collect the cross-reference in the desired order to begin with, to
> avoid the cost of sorting/reversing.

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.

> And finally, Info-follow-reference is called by other functions, so we
> should make sure we don't break them by changing the order.

Yes, though given my proposed change is in the call to interactive I believe
it shouldn't affect other non-interactive callers of it.

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.

Howard





This bug report was last modified 3 years and 17 days ago.

Previous Next


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