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: Mon, 30 Aug 2021 05:45:07 +0300 Message-ID: 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> <8335qvs8re.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="13464"; 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 Mon Aug 30 04:46:09 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 1mKXJJ-0003LW-1x for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Aug 2021 04:46:09 +0200 Original-Received: from localhost ([::1]:43382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKXJH-0004pa-VP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Aug 2021 22:46:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKXJC-0004p2-4g for bug-gnu-emacs@gnu.org; Sun, 29 Aug 2021 22:46:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKXJB-0008DU-SW for bug-gnu-emacs@gnu.org; Sun, 29 Aug 2021 22:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mKXJB-0007rD-NI for bug-gnu-emacs@gnu.org; Sun, 29 Aug 2021 22:46: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: Mon, 30 Aug 2021 02:46: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.163029152430160 (code B ref 50067); Mon, 30 Aug 2021 02:46:01 +0000 Original-Received: (at 50067) by debbugs.gnu.org; 30 Aug 2021 02:45:24 +0000 Original-Received: from localhost ([127.0.0.1]:57877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKXIU-0007qJ-Kd for submit@debbugs.gnu.org; Sun, 29 Aug 2021 22:45:24 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:36454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mKXIS-0007q0-Aa for 50067@debbugs.gnu.org; Sun, 29 Aug 2021 22:45:17 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id 79-20020a1c0452000000b002e6cf79e572so13633014wme.1 for <50067@debbugs.gnu.org>; Sun, 29 Aug 2021 19:45:16 -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=QiqaxBQ5jI1Rwa2GX0HfPiuqyRbyaTOpEk9j148dXMM=; b=ZNjZZts+smp2z+SCJ+2E+zVGTE+NS93Vdrl4FzXrnodRU+XOI9EdTH4H0cOANkRp/u CT/GzSX0jaumk8PVKpNZyKfd0iqTRTnUfxY7yqm9Fw3g7MpE0XU/JNF8CmUWEu6kT6ja jf6zvpu/GncDyA3XVMzhK8mtj1KvcCBSoRClT8ah86XKK6xuAzZOQCRBUsxYxFDWkt0x n0f3Oa30CzAzdN5XNbR4gc5R+Uhu5VV2hT9LzNXTGk41MZhWDXVvyCRZYvvSgjgwGez6 gKQ6U9rCotIIJaNfjhkc+aopoN0wVC1zn5p7rlJ3jPtWBCb96O5cwWe2LEVTTG4Jupwt n0pw== 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=QiqaxBQ5jI1Rwa2GX0HfPiuqyRbyaTOpEk9j148dXMM=; b=n9//iezLdrmR3jOZKq0zkmOJhznZmy4UHytWW8L96QvfKxOf3to3AQxE390E0Af2Wx /zWOMw2JS8E7bE1cq3tnYujoYjpkFF3U1p5dq9/oU9koS/BQ1bev2yhJK041UYZ6qaId J3k099qsHwkdL4k9vzulUgEGMtzSsvsOAitVy7A9Nsn9fJsun1vVITuwbbLGZDp/wbUS gIcYZf8TIMaIabtcG4eAGi3BdGLR13F2PeHLhCrUH1gb0UdP0jq5fQRjJIwy/bwQIpfv IapVMTm2twFMwmaB4iNi6qnDe319XbdQroc3Inm+K5dZWpcFok/bpC2a8JPr1S7GV1B4 GaKQ== X-Gm-Message-State: AOAM532JY8qFeIJCbypLSu2lGwKz1sKSqecmXUxgmbLR+3CdrbPrpZdB 50vRNqiXOzH75PVuyhk8YN3XEOdM4+A= X-Google-Smtp-Source: ABdhPJxnSfzD6XJtWM9ZlwpQ+cXionF1KWyE+QHix+ESEMh+F6cXjKYIOnhtSGKxKFp94XsHb7+jFg== X-Received: by 2002:a7b:c041:: with SMTP id u1mr19238785wmc.95.1630291510440; Sun, 29 Aug 2021 19:45:10 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l21sm12110481wmh.31.2021.08.29.19.45.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Aug 2021 19:45:09 -0700 (PDT) In-Reply-To: <8335qvs8re.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:213001 Archived-At: On 27.08.2021 09:26, Eli Zaretskii wrote: >> 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. Fair enough. >> 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. I see. This does not correspond to my usage and expectations, but, fingers crossed, this addition will satisfy the needs of other former users of 'find-tag' as well. >> 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". All right. You still prefer the original patch, then? >>>> 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. Cool. >>>> 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. All right.