From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#54175: 27.2; Info-follow-reference completions in reverse order Date: Sun, 27 Feb 2022 09:17:07 +0200 Message-ID: <831qzopymk.fsf@gnu.org> References: <7A89A71F-708C-4217-989C-2E9990759E13@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11674"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54175@debbugs.gnu.org To: Howard Melman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 27 08:18:37 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nODpE-0002uK-V6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 08:18:37 +0100 Original-Received: from localhost ([::1]:43974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nODpD-0005Ee-IY for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Feb 2022 02:18:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nODoi-00052m-2X for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 02:18:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34624) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nODof-0005DY-Vj for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 02:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nODof-0004nd-Js for bug-gnu-emacs@gnu.org; Sun, 27 Feb 2022 02:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Feb 2022 07:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54175 X-GNU-PR-Package: emacs Original-Received: via spool by 54175-submit@debbugs.gnu.org id=B54175.164594624818409 (code B ref 54175); Sun, 27 Feb 2022 07:18:01 +0000 Original-Received: (at 54175) by debbugs.gnu.org; 27 Feb 2022 07:17:28 +0000 Original-Received: from localhost ([127.0.0.1]:56754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nODo8-0004mp-2G for submit@debbugs.gnu.org; Sun, 27 Feb 2022 02:17:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nODo6-0004me-LP for 54175@debbugs.gnu.org; Sun, 27 Feb 2022 02:17:26 -0500 Original-Received: from [2001:470:142:3::e] (port=45648 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nODo1-000597-F9; Sun, 27 Feb 2022 02:17:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=q9H/1AS+mIN+K2iEvlN+bTsNlHD3fZpUjKjcdS9yx9s=; b=GNPP2pO6rXF3 ueQ1Iv5P3JuFV0DaUYhUej47lbAjmHn5ECCuaEwBVwpZsQh9wAaSfpIb96K3JWTCh7Jw/yYTVqkLX YAwmTbdM2rmDZ4fsSqsCWTCCp7cjmIUCU89QuE4Xxfgd8pDY51G5FCxgw2DyPpCRkxigrqmBRjD+T iUS8ck43Yh5W012myELSlariDqekmlDZuyc/mHfUEJu3Mrr7xLdH30MuaXph6YdIIS5PnrOOD7qYw /bQeCBQi8Syh6XOPvvoudu5j+ZmYs9b6q8GB87yUqvREqDokZKUiHoYAki4AoHlvIlX23XWFv/uu8 E4BnUfdsAuNBMXyx+lDNTQ==; Original-Received: from [87.69.77.57] (port=4745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nODo0-0004eJ-Dn; Sun, 27 Feb 2022 02:17:21 -0500 In-Reply-To: <7A89A71F-708C-4217-989C-2E9990759E13@gmail.com> (message from Howard Melman on Sat, 26 Feb 2022 19:17:21 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:227700 Archived-At: > From: Howard Melman > 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?