From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#44611: Prefix arg for xref-goto-xref Date: Sun, 15 Nov 2020 21:51:48 +0200 Organization: LINKOV.NET Message-ID: <875z67gd6z.fsf@mail.linkov.net> References: <87k0up68e4.fsf@mail.linkov.net> <99772eb6-5a4e-7cf6-259d-0e9429e6bf97@yandex.ru> <878sb3n0a9.fsf@mail.linkov.net> <48f942f9-a557-0185-25fe-612e78cd9071@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8494"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 44611@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 15 21:29:15 2020 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 1keOeA-00024X-Um for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Nov 2020 21:29:14 +0100 Original-Received: from localhost ([::1]:40952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1keOe9-000060-Sl for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Nov 2020 15:29:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34540) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1keOdz-0008Q0-Cu for bug-gnu-emacs@gnu.org; Sun, 15 Nov 2020 15:29:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1keOdz-0005Nz-2G for bug-gnu-emacs@gnu.org; Sun, 15 Nov 2020 15:29:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1keOdy-0004jq-Tn for bug-gnu-emacs@gnu.org; Sun, 15 Nov 2020 15:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Nov 2020 20:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44611 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 44611-submit@debbugs.gnu.org id=B44611.160547211618128 (code B ref 44611); Sun, 15 Nov 2020 20:29:02 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 15 Nov 2020 20:28:36 +0000 Original-Received: from localhost ([127.0.0.1]:54244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1keOdY-0004iJ-Cx for submit@debbugs.gnu.org; Sun, 15 Nov 2020 15:28:36 -0500 Original-Received: from relay12.mail.gandi.net ([217.70.178.232]:44923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1keOdW-0004i5-9t for 44611@debbugs.gnu.org; Sun, 15 Nov 2020 15:28:34 -0500 Original-Received: from mail.gandi.net (m91-129-97-46.cust.tele2.ee [91.129.97.46]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 12BFD200004; Sun, 15 Nov 2020 20:28:26 +0000 (UTC) In-Reply-To: <48f942f9-a557-0185-25fe-612e78cd9071@yandex.ru> (Dmitry Gutov's message of "Sun, 15 Nov 2020 03:05:16 +0200") 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:193377 Archived-At: > The original justification for this binding (authored by Joao) was that by > using it we indicate that the Xref buffer is used for "completion" (picking > one result), rather then iterating over multiple matches. > > That's why it's TAB, because "TAB completion", apparently. Overall, it's > not obvious, but it kinda makes sense. This interpretation of picking one result doesn't fit into my workflow: I use RET to iterate over multiple matches, then need to close the *xref* window after visiting the last match, so TAB makes no sense in this case. I'd expect TAB rather to iterate over multiple matches, i.e. like TAB in browsers go to the next match. Even in the *Completions* buffer TAB moves to the next completion. And in icomplete-mode the closest analogy to picking one result is 'C-j' (icomplete-force-complete-and-exit).