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#44611: Prefix arg for xref-goto-xref Date: Tue, 22 Dec 2020 17:53:37 +0200 Message-ID: <83pn31rg5a.fsf@gnu.org> 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> <875z67gd6z.fsf@mail.linkov.net> <72e9e5e9-651f-401f-2e26-faaac1b7fdb5@yandex.ru> <87v9cxleff.fsf@mail.linkov.net> <834kkhtaxm.fsf@gnu.org> <874kkgswg2.fsf@mail.linkov.net> <83v9cwsct7.fsf@gnu.org> <87k0tab3y0.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3355"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, joaotavora@gmail.com, 44611@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 22 16:55:22 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 1krk0N-0000iI-El for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Dec 2020 16:55:19 +0100 Original-Received: from localhost ([::1]:41998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krk0M-00034z-De for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Dec 2020 10:55:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krk06-00033a-8U for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 10:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1krk06-0003l6-0p for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 10:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1krk05-0002UC-VH for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 10:55: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: Tue, 22 Dec 2020 15:55:01 +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.16086524429469 (code B ref 44611); Tue, 22 Dec 2020 15:55:01 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 22 Dec 2020 15:54:02 +0000 Original-Received: from localhost ([127.0.0.1]:50768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krjz8-0002Sf-49 for submit@debbugs.gnu.org; Tue, 22 Dec 2020 10:54:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krjz4-0002S8-4c for 44611@debbugs.gnu.org; Tue, 22 Dec 2020 10:54:00 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60491) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krjyx-0003PT-Bi; Tue, 22 Dec 2020 10:53:51 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1krjyw-0001jz-Iq; Tue, 22 Dec 2020 10:53:51 -0500 In-Reply-To: <87k0tab3y0.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 22 Dec 2020 10:58:35 +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:196579 Archived-At: > From: Juri Linkov > Cc: dgutov@yandex.ru, joaotavora@gmail.com, 44611@debbugs.gnu.org > Date: Tue, 22 Dec 2020 10:58:35 +0200 > > >> And since the new keybinding have no disastrous effect, it would safer > >> for the users to adapt to the new keybinding. > > > > What disastrous effects? AFAICT, TAB buries the XREF buffer, which is > > not a disaster. > > It takes the same amount of efforts to bring it back: either by finding > the buried buffer in the buffer list, or running project-find-regexp again. That doesn't sound like a disaster. It just means "C-x b" won't offer that buffer as the first completion candidate. > > More generally, I think it's wrong to try to make XREF buffers behave > > like *Grep* buffers. They are different beasts, I think we > > established this long ago, when Xref was added to Emacs (I think I > > even made a comment regarding the difference, and Dmitry responded to > > the effect that this was intended). *XREF* and *Grep* look > > differently and behave differently, and it's impossible to make them > > be similar enough. > > They might be different when *xref* is used as a completions buffer > when the *xref* buffer is created by 'M-.' (xref-find-definitions). > > Moreover, now it's possible to use the real *Completions* buffer by > customizing xref-show-definitions-function to xref--show-defs-minibuffer. > Even is this case TAB doesn't close the *Completions* buffer. > > But a completely separate case is when the *xref* buffer is created > by such grep-like commands as project-find-regexp. Perhaps those other cases need a special variant of xref-mode, where TAB could have a binding you'd like to see. > So currently there are two different uses of the *xref* buffer: > > 1. as a transient completions buffer that could be buried > after a completion is selected from the buffer; > 2. as a grep buffer for visiting the found matches. > > In the second case, it's natural to type TAB to navigate results. If you mean that the first use is as a kind of "completion" buffer, then I disagree: at least by default it doesn't look and doesn't behave like a list of completions. It's an entirely different beast, unlike anything else I know of that we have in Emacs core. > Should these cases use different modes with different buffer names? > Such as a buffer name *xgrep*? I think it's a slippery slope to take a minor very specialized mode and start adding variants to it. But if you insist on having TAB go to the next candidate, perhaps we will have no other choice than to take that path.