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, 27 Dec 2020 18:20:01 +0200 Organization: LINKOV.NET Message-ID: <87h7o7bfoe.fsf@mail.linkov.net> References: <87k0up68e4.fsf@mail.linkov.net> <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> <83a6u2nm8o.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="17819"; 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: dgutov@yandex.ru, joaotavora@gmail.com, 44611@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 27 17:26:39 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 1ktYsP-0004VZ-LJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Dec 2020 17:26:37 +0100 Original-Received: from localhost ([::1]:41894 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktYsO-0004Kz-LV for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 27 Dec 2020 11:26:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41168) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktYrq-0004IA-L4 for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2020 11:26:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50005) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ktYrq-0005vI-AI for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2020 11:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ktYrq-0005JJ-6B for bug-gnu-emacs@gnu.org; Sun, 27 Dec 2020 11:26: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, 27 Dec 2020 16:26: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.160908633720358 (code B ref 44611); Sun, 27 Dec 2020 16:26:02 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 27 Dec 2020 16:25:37 +0000 Original-Received: from localhost ([127.0.0.1]:33312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktYrR-0005IF-6q for submit@debbugs.gnu.org; Sun, 27 Dec 2020 11:25:37 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:41559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ktYrP-0005Hu-C4 for 44611@debbugs.gnu.org; Sun, 27 Dec 2020 11:25:35 -0500 X-Originating-IP: 91.129.99.98 Original-Received: from mail.gandi.net (m91-129-99-98.cust.tele2.ee [91.129.99.98]) (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 60C94E0005; Sun, 27 Dec 2020 16:25:26 +0000 (UTC) In-Reply-To: <83a6u2nm8o.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Dec 2020 13:44:39 +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:196801 Archived-At: > 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? No, this is not the reason to do something similar. I already explained the reason below, i.e.: "Unlike the above examples, in Emacs everything is configurable, so you can easily add to the init file". > 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. The notion "conservative" is irrelevant here, because TAB was bound in xref recently, this discussion is not about changing some long-established bindings. >> 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? This is not about my personal preferences. For example, my preference is not to add tab-line-tab-face-special to tab-line-tab-face-functions, but since everyone wants it, I had to install it as the default value. >> 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. This would be the worst thing to do. For Emacs 28 we are working to provide grep-like experience in the xref output, but not adding a key binding compatible with grep mode would harm our efforts. >> > 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. There are two modes: xref-show-xrefs and xref-show-defs. xref-show-xrefs is similar to grep, whereas xref-show-defs resembles the Completion UI where C-j makes sense. >> > 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. I think this is a good idea for completion-like xref-show-defs, but not for grep-like xref-show-xrefs because in grep-mode 'C-c C-c' is bound to compile-goto-error that doesn't quit window.