From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Howard Melman Newsgroups: gmane.emacs.bugs Subject: bug#54175: 27.2; Info-follow-reference completions in reverse order Date: Wed, 04 May 2022 10:46:58 -0400 Message-ID: References: <7A89A71F-708C-4217-989C-2E9990759E13@gmail.com> <831qzopymk.fsf@gnu.org> <83bkysntjv.fsf@gnu.org> <5EDDF26F-4350-469D-B98C-99D7743E9424@gmail.com> <83a6ecnsn5.fsf@gnu.org> <1C706C79-657B-4B02-B028-0D1BEB448A8B@gmail.com> <838rtwnrms.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36475"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (darwin) To: 54175@debbugs.gnu.org Cancel-Lock: sha1:k6za+t2+ewFBh9qzz5vb49MNWK8= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 04 16:48:35 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 1nmGIs-0009KD-Rc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 May 2022 16:48:34 +0200 Original-Received: from localhost ([::1]:53598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmGIr-00069o-VZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 May 2022 10:48:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmGIM-0005Uw-OP for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 10:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49761) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmGIM-0007d9-Fe for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 10:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nmGIM-00067S-Cs for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 10:48:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <7A89A71F-708C-4217-989C-2E9990759E13@gmail.com> Resent-From: Howard Melman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 May 2022 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54175 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.165167564123319 (code B ref -1); Wed, 04 May 2022 14:48:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 4 May 2022 14:47:21 +0000 Original-Received: from localhost ([127.0.0.1]:43658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmGHg-000643-Nj for submit@debbugs.gnu.org; Wed, 04 May 2022 10:47:21 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:60394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmGHd-00063s-ON for submit@debbugs.gnu.org; Wed, 04 May 2022 10:47:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmGHd-0004bx-Gt for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 10:47:17 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:52872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmGHY-0007VF-Mk for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 10:47:17 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nmGHR-000799-NA for bug-gnu-emacs@gnu.org; Wed, 04 May 2022 16:47:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:231389 Archived-At: To follow up on this from Feb. Here's a summary of what's been discussed. My original report: > 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)) > Eli argued that this would put a burden on users who stick with the default completion system. I showed that his example degenerate case had no meaningful performance impact. He also asked why is this order more meaningful. It seems obvious to me that the order the references appear in the text is more meaningful than the reverse of that order. And I showed a common use case of visiting a page and wanting to follow one of the first references without having to move point, particularly if the node fits on one page. Eli proposed some different order could be more useful. I said "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." Additionally, I point out that this change doesn't affect that if point is on a reference the default is still that reference. I also pointed out: > 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. I think the order of a menu is more clearly a bug than of a completion table, but I think both should be fixed. My preference would be that the order in a menu be the order of references found in the text and that Info-follow-reference candidates use the same order. I think alphabetical is also reasonable for this menu and could be different from Info-follow-reference, but I don't see how it's useful for either to be in the reverse order as found in the text. I still think the proposed one line fix (applied in both places) is the easiest and least risky change. -- Howard