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#50067: Context menus Date: Fri, 27 Aug 2021 09:26:45 +0300 Message-ID: <8335qvs8re.fsf@gnu.org> References: <83sfz639lh.fsf@gnu.org> <8735r6ppf0.fsf@mail.linkov.net> <83o89u37gh.fsf@gnu.org> <87wnohx5zd.fsf@mail.linkov.net> <831r6p3lzc.fsf@gnu.org> <87o89sh96g.fsf@mail.linkov.net> <837dgg1hdg.fsf@gnu.org> <87mtpcf79p.fsf@mail.linkov.net> <83zgtcyp2k.fsf@gnu.org> <56454B2B-0250-4BC6-BC26-E1C5579ACF49@acm.org> <83eeanyrm5.fsf@gnu.org> <4BC1074D-DE75-4303-8385-B70BAACFCDA0@acm.org> <83czq7youc.fsf@gnu.org> <32ef6b91-107c-d7e5-b103-0ff062bf8ebd@yandex.ru> <83y28twahy.fsf@gnu.org> <7af845e0-1f19-61fc-65e0-b23fac3927aa@yandex.ru> <83v93wx5ny.fsf@gnu.org> <83r1ekwfrd.fsf@gnu.org> <871r6ki6aw.fsf@mail.linkov.net> <838s0otl6b.fsf@gnu.org> <0273902a-1f93-c643-da26-ab314d6d2db4@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alan@idiocy.org, mattiase@acm.org, juri@linkov.net, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, larsi@gnus.org, 50067@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 27 08:28:11 2021 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 1mJVLW-0004eV-DD for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Aug 2021 08:28:10 +0200 Original-Received: from localhost ([::1]:59560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJVLV-0005OJ-Bx for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Aug 2021 02:28:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJVLO-0005JJ-9P for bug-gnu-emacs@gnu.org; Fri, 27 Aug 2021 02:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39557) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mJVLN-0004v6-V7 for bug-gnu-emacs@gnu.org; Fri, 27 Aug 2021 02:28:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mJVLN-00049w-S9 for bug-gnu-emacs@gnu.org; Fri, 27 Aug 2021 02:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Aug 2021 06:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50067 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 50067-submit@debbugs.gnu.org id=B50067.163004564515941 (code B ref 50067); Fri, 27 Aug 2021 06:28:01 +0000 Original-Received: (at 50067) by debbugs.gnu.org; 27 Aug 2021 06:27:25 +0000 Original-Received: from localhost ([127.0.0.1]:51103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJVKh-00048v-5C for submit@debbugs.gnu.org; Fri, 27 Aug 2021 02:27:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJVKf-00048i-8I for 50067@debbugs.gnu.org; Fri, 27 Aug 2021 02:27:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40358) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJVKU-0004BH-Hx; Fri, 27 Aug 2021 02:27:06 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1032 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJVKT-0003iK-3Q; Fri, 27 Aug 2021 02:27:06 -0400 In-Reply-To: <0273902a-1f93-c643-da26-ab314d6d2db4@yandex.ru> (message from Dmitry Gutov on Fri, 27 Aug 2021 00:05:39 +0300) 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:212800 Archived-At: > Cc: juri@linkov.net, alan@idiocy.org, mattiase@acm.org, > homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, larsi@gnus.org, > 50067@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 27 Aug 2021 00:05:39 +0300 > > I think I remember now why it didn't make sense to me to have this > behavior OOTB: I think the main goal of the user who calls > xref-find-definitions is, usually, to pick one definition they wanted to > visit. Which also means having the xref buffer dismissed at the end. That's one use case. Another use case is when the candidates are all related to some issue the user is working on, and therefore leaving the xref buffer displayed for a long time is what they want. > With the patch under discussion we automatically jump to the first > location. We can even iterate through locations with > next-error/previous-error (M-g M-n/M-g M-p). But to close > (quit/kill/etc) the list of locations, you have to switch back to its > window and press 'q'. Didn't that look like a bother to you? No. In my case, I just never bother to dismiss the xref buffer. The window showing it is a small one, and sooner or later the xref buffer gets replaced by *Help* or ChangeLog or one of the other buffers I display at the bottom of the frame. > Here's how it could look instead: > > 1. When you press M-., the first location is "shown", but not jumped to. > The focus remains on the Xref window, with point on its first item (the > arrow beside it is visible, like you wanted). Location is visible in the > other window, and we can either visit it and dismiss the Xref buffer > (with 'C-u RET'), simply visit it with 'RET', or look at the other > locations with 'n'/'p'. This AFAIU corresponds to the situation where the user is not certain which of the candidates is the one he/she wants. I don't see how it fundamentally differs from the original patch, since "M-g M-n" (or "C-x `", which is what I use) isn't less convenient than 'n' followed by "C-x o". It might be more convenient to those who like to dismiss the xref buffer, but (a) I'm not one of them, and (b) one can dismiss it without going into it with "C-x 4 C-o". > And you could also use a "transient" show-definitions-function like: > > (setq xref-show-definitions-function > #'xref-show-definitions-buffer-at-bottom) > > Then you'd only need to press RET in the results buffer to jump and > dismiss the results buffer. Do a lot of people really like to dismiss the xref buffer? In any case, I think questions about this aspect are better answered by someone who does like to dismiss the buffer, because the issue simply doesn't bother me enough to give you any useful input. > 2. Simply have point move to the first location in the list (rather than > remain on the group name). From there, the user can press 'C-o' to show > the location without visiting, or 'RET', or 'C-u RET' like described > above. I understand this does not fit your prior workflows, but it does > require the least number of button presses in the scenario "go to the > first location and dismiss the Xref buffer", especially in combination > with the (setq xref-show-definitions-function ...) form above. That's just a minor change in what we have now. I don't object to such a change, not even by default, but it isn't what we were discussing until now. > >> 1. Does the new behavior work okay window management-wise (it does > >> occupy +1 window, after all)? > > > > Not sure I understand the question: we pop up an additional window > > when there are more than one candidate even without this option, so > > why do you say "+1 window"? Maybe you had some recipe in mind that I > > didn't try? > > It's "+1 window" compared to how 'find-tag' worked/works, which I assume > is the target. No, I think xref is actually an improvement in this department, because it shows the list of candidates instead of letting the user guess how many are there. > >> 2. Should this setting also extend to other commands like > >> xref-find-references? > > > > Not necessarily. Perhaps xref-auto-jump-to-first-definition should be > > tri-state, to allow users to request the same with > > xref-find-references as well? > > Sure. Or we can have two variables, especially if we end up cramming > different variations of behavior into them. > > We can do a lot of things. What would help, is better knowledge about > what people *want* to do. If we don't want to take a guess, I'd suggest leaving the option as it is, affecting only xref-find-definitions, and extend it to other commands as user requests arrive.