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: Fri, 25 Dec 2020 13:44:39 +0200 Message-ID: <83a6u2nm8o.fsf@gnu.org> References: <87k0up68e4.fsf@mail.linkov.net> <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> <83pn31rg5a.fsf@gnu.org> <877dp9ycq6.fsf@mail.linkov.net> <837dp8r250.fsf@gnu.org> <4a0c8870-e2e7-97c7-5808-afa704ebee13@yandex.ru> <83mty4pj0u.fsf@gnu.org> <1d9bf365-224f-bb41-d79c-e22d110b41e3@yandex.ru> <83eejgpbs8.fsf@gnu.org> <9fa9d286-4497-baa9-15cd-1ef31651781f@yandex.ru> <83a6u4p8nz.fsf@gnu.org> <3c740ee3-cc1c-e2e3-d540-7be0b37d91ef@yandex.ru> <83pn2znloa.fsf@gnu.org> <87pn2zlzy3.fsf@mail.linkov.net> <83k0t7ndbs.fsf@gnu.org> <87wnx6z1gs.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26417"; 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 Fri Dec 25 12:46:17 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 1kslY1-0006kt-AF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 12:46:17 +0100 Original-Received: from localhost ([::1]:36870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kslXz-00039E-SP for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 06:46:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kslXm-000393-Is for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 06:46:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kslXm-0006EK-A4 for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 06:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kslXm-0007kh-6u for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 06:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Dec 2020 11:46: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.160889670729731 (code B ref 44611); Fri, 25 Dec 2020 11:46:02 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 25 Dec 2020 11:45:07 +0000 Original-Received: from localhost ([127.0.0.1]:56821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kslWs-0007jT-Qc for submit@debbugs.gnu.org; Fri, 25 Dec 2020 06:45:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kslWq-0007ib-23 for 44611@debbugs.gnu.org; Fri, 25 Dec 2020 06:45:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34419) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kslWk-0005iS-D6; Fri, 25 Dec 2020 06:44:58 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2287 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kslWj-0000ek-E2; Fri, 25 Dec 2020 06:44:57 -0500 In-Reply-To: <87wnx6z1gs.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 25 Dec 2020 11:20:19 +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:196697 Archived-At: > From: Juri Linkov > Cc: dgutov@yandex.ru, joaotavora@gmail.com, 44611@debbugs.gnu.org > Date: Fri, 25 Dec 2020 11:20:19 +0200 > > >> With further development of the search commands based on xref, more > >> users perceive it as a grep replacement, that however is not based > >> on grep mode, so this is a good reason to make xref keybindings more > >> compatible with grep mode. > > > > You didn't answer my question why not use the format we use in *grep* > > buffers or *occur* buffers. > > Sorry, I don't know an answer to this question. But fortunately > Dmitry answered your question. He did, yes. > Big corporations don't afraid making much more fundamental changes > that affect billions of users. For example, on smartphone OS > they can do such a change that on the Task list the same gesture > will remove the wrong task than on older versions. Also major sites > with billions of users often change their UI completely without hesitation. > > So I don't understand such extreme precautions. Do you think that what "big corporations" do is okay? If you do, then I understand why you consider it OK for us to do something similar. But if you don't, then why do you suggest that we follow bad examples? I don't think frequent changes in the UI and the defaults are a Good Thing. Each time I upgrade some software which comes from those big corporations, I have to waste some significant time to get many of my previous defaults back, disable or reconfigure annoying new features etc. Moreover, no matter how conservative we are in Emacs with breaking backward compatibility, we are still being occasionally accused of not being conservative enough. So evidently, veteran users don't like such changes to happen too frequently. Looking at NEWS for past releases, I conclude that we indeed didn't make such changes. > Unlike the above examples, > in Emacs everything is configurable, so you can easily add to the init file: > > (define-key xref--xref-buffer-mode-map (kbd "TAB") #'xref-quit-and-goto-xref) This works both ways: if you want TAB to do something other than its default, you can rebind it for you, right? > But having no command bound to TAB is a lose-lose situation because > users of grep-like xref commands will have less compatible keys. I didn't suggest unbinding TAB, I suggested to leave its current binding as it was in Emacs 27 and older. > > And why C-j? That's LFD, a key more suitable for acting on something > > at point, not quitting the buffer. > > The initial xref UI was closer to completion UI, so C-j makes it consistent > with icomplete mode for users who still perceive xref as completion UI. That contradicts what Dmitry said: that the current Xref UI moves away of the completion UI, and towards compilation-mode and grep-mode. There, deleting the window with C-j will look odd, I think. > > Why not 'q' (for "quit") or 'b' (for "bury")? > > 'xref-quit-and-goto-xref' also jumps to xref, not only quits, > but 'q' and 'b' should only quit. That's not a catastrophe, but if you want, we could use "C-c C-c" instead, as that is used in some other modes for similar effect.