From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#50067: Context menus Date: Fri, 27 Aug 2021 00:05:39 +0300 Message-ID: <0273902a-1f93-c643-da26-ab314d6d2db4@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4956"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 26 23:06:10 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 1mJMZe-00012f-05 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Aug 2021 23:06:10 +0200 Original-Received: from localhost ([::1]:33780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJMZc-0004Ep-MO for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Aug 2021 17:06:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37060) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJMZW-0004ET-FV for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 17:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mJMZW-0002Jy-3K for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 17:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mJMZV-0000Xq-Ny for bug-gnu-emacs@gnu.org; Thu, 26 Aug 2021 17:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Aug 2021 21:06: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.16300119552082 (code B ref 50067); Thu, 26 Aug 2021 21:06:01 +0000 Original-Received: (at 50067) by debbugs.gnu.org; 26 Aug 2021 21:05:55 +0000 Original-Received: from localhost ([127.0.0.1]:50618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJMZJ-0000XS-OS for submit@debbugs.gnu.org; Thu, 26 Aug 2021 17:05:54 -0400 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:43663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mJMZH-0000XD-UI for 50067@debbugs.gnu.org; Thu, 26 Aug 2021 17:05:48 -0400 Original-Received: by mail-wm1-f49.google.com with SMTP id o39-20020a05600c512700b002e74638b567so3008916wms.2 for <50067@debbugs.gnu.org>; Thu, 26 Aug 2021 14:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZoBHAjvXHQYO9xcrFSPDdqr2rcvjdgUe/xmPs2/eurI=; b=L5pIx1N4xOnnlgra58YXFEUrETN8XUcRCV5oNtKcU6GSRelt1LpzaTS6uKpwrYvg9l G06m4p3z6AxHJ4WUI6Yr2QEIpKz7dzm5GB+WWFeXQQYN5CslurBq1rYYKB8g3RCEFhKU JxxugSGqberwK1hDYeWaJIYtCPQmYEoc7nFL1R+pCaZXKEglzKB8jAr7tV9DWlAGV0Iq uSLcL6nwgFOGTLKXwAM2E1IzXjIovd0djGtrTUqWvti357ooMdprQgjbtVmpn7abpidB jqzT0N0Ga2uZxrQWPCKeJtA9MYyb6lwr1pfTq5oYRVnv53svxroS2WBjjsrFjRSf1ddQ dBdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZoBHAjvXHQYO9xcrFSPDdqr2rcvjdgUe/xmPs2/eurI=; b=EGZLF1r0MgAk+1OU2CTC4pb01tSIHHiwnj5yORR/xCRjumrYkD9CrGW6zYMTx7cL7E MQIS7MUxrnXBbU8VwPenspf+LqQpK/PPEevtYl9DSgl8CZSfH62g5bgbKuBpq8T51qmz RBSfC6QMybxhnQfipggUDjEdVoCySR/p2LlZLwY8STOES1u/Gr3TxFLbWnc0drHDpoVb wp41Zq5tTl1WDczdybrc+e8AYRg1SP5kicuvkpBq8tudRCrusCgqpOWGAcHGU1LECSQH DQuo+kx8gfyHgCiAy2DXDdUuixJg32VQlJAl6MyX+sYijfJ1vuaMgi6kEAoGR5am0N1z kiEg== X-Gm-Message-State: AOAM531bi3ZbHvLp62Fmi6ZOvsXmIJFtoVKlbqWoTGALJhiLZAVOW/bg AS1safoyA5Gx9Oo9goJeVlXLsqr0MWk= X-Google-Smtp-Source: ABdhPJycwaPAf2u7LXvF/XwRru+dKQZmeKQXg3YO8JmFMeVmhO7zt26cFYeAmGJgIHTAcg/SsAZVRQ== X-Received: by 2002:a7b:cc07:: with SMTP id f7mr7961369wmh.145.1630011942059; Thu, 26 Aug 2021 14:05:42 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s17sm9490625wmj.12.2021.08.26.14.05.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 14:05:41 -0700 (PDT) In-Reply-To: <838s0otl6b.fsf@gnu.org> Content-Language: en-US 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:212764 Archived-At: On 26.08.2021 16:01, Eli Zaretskii wrote: >> Cc: 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: Tue, 24 Aug 2021 20:59:40 +0300 >> >>>> An option to display the first match right away will be most >>>> appreciated, thanks. >>> Like compilation-auto-jump-to-first-error. >> >> So we even have a precedent, very good. >> >> Could you both check out the attached patch? >> >> Together with (setq xref-auto-jump-to-first-definition t) > > Thanks, this looks very handy, I will definitely use it. Very good. Let's now discuss a couple of minor alterations. We can always go back to this patch if we don't decide on anything better. 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. 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? 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'. For this to work, the patch will need to change xref--auto-jump-first, swapping + (xref-next-line-no-show) + (xref-goto-xref)) for + (xref-next-line) The new option's name would probably be different too. 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. 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. >> Questions for feedback: >> >> 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. So it's still not the same behavior. >> 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.