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#44611: Prefix arg for xref-goto-xref Date: Fri, 25 Dec 2020 17:24:20 +0200 Message-ID: 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> <83a6u2nm8o.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="33325"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: joaotavora@gmail.com, 44611@debbugs.gnu.org To: Eli Zaretskii , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 25 16:25:10 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 1ksoxq-0008Yd-Ez for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 16:25:10 +0100 Original-Received: from localhost ([::1]:38924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksoxp-0007NN-AP for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 10:25:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksoxi-0007NG-7y for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 10:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ksoxh-0007nS-W6 for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 10:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ksoxh-0006mN-Ru for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 10:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Dec 2020 15:25:01 +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.160890987126019 (code B ref 44611); Fri, 25 Dec 2020 15:25:01 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 25 Dec 2020 15:24:31 +0000 Original-Received: from localhost ([127.0.0.1]:58030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksoxD-0006la-2V for submit@debbugs.gnu.org; Fri, 25 Dec 2020 10:24:31 -0500 Original-Received: from mail-ed1-f54.google.com ([209.85.208.54]:40569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksoxB-0006lM-GG for 44611@debbugs.gnu.org; Fri, 25 Dec 2020 10:24:30 -0500 Original-Received: by mail-ed1-f54.google.com with SMTP id h16so4341268edt.7 for <44611@debbugs.gnu.org>; Fri, 25 Dec 2020 07:24:29 -0800 (PST) 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=2NU5wjJ4b5+Q5EPS97Ag3N9dlbY03WNXkw/3wuGenP4=; b=fp5A4M+dzN9o8zYMI5BDQuLPLeJ2WfQRQsDsu/ZfY6poLSsPoq+nE0Uzr+c9vgaWb4 C8J6gxZVm+KqLdLkpJMVnxBjTsaQe5sQgrFFBl+eP7KHAsuZRSIB37QGQ68MOjleMCYG 36vkdYEW7AkIVWr7N5w9neTuvdpGxTtJfxm7QkI+A8tnpJMcTTYFM3mME7A8hxdA3wyR +uCIQnbPpCD7aWQVrcQcTYkOmnC9vQdRACy8thCmL6Gp9+a1UQVm0CV+phWNRYF3fwRq 5eE8r56/KAD0DuGueMB3UMA+VkyWCEiGFxeSVHg9qtKGmHbBl2Wa3OY/oNlXpGJhgBHw z9Xw== 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=2NU5wjJ4b5+Q5EPS97Ag3N9dlbY03WNXkw/3wuGenP4=; b=uGMQ9APO+xwQdtnm+eDhInAHGTXHlDfTTX7ikX6oWUbN/pciQvLp1NxctI2kRVLyDG u+jBT7I3V7A17zsUf+dojw5UZqoG56/R7p5MOr0U4jcaJF+dfEN8UlErKJyotL0DuyXF T+0gB19s9vSk0sbDi63pVaHW2VqaWHbBnuTIasZMV0PKSZ1cYi5V0K6laVOSbYPRMXy7 tTEHO7FdOLWfb1IEIyVflF+gmc0Pf7Rqo6tAz3uIWmUZftX+YiU2ieRpDCgloCa+1oBJ UOPpGBdj/F+SYu0CkNsdBSmHkEHVS+TJLNxa1QWLqWfkRbToj4U7f3lRBjH6oHcSi0jW TLmw== X-Gm-Message-State: AOAM530Jqn2HZp2AtvRgI51ra1tFodnA5ex2D5YXemTEJBsCBIQhmoZV henMa44YthJOl2zRngGRRD/mK1qBbHzDxA== X-Google-Smtp-Source: ABdhPJxc6k11WHnrmGhiZ+DUZmsps6+HRb4Sz50fTNFFRjjFx+fmjj0KJp24mUI5UJmQppb3HUfVjg== X-Received: by 2002:aa7:df91:: with SMTP id b17mr33110730edy.272.1608909863321; Fri, 25 Dec 2020 07:24:23 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t15sm14476701ejx.88.2020.12.25.07.24.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Dec 2020 07:24:22 -0800 (PST) In-Reply-To: <83a6u2nm8o.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:196703 Archived-At: On 25.12.2020 13:44, Eli Zaretskii wrote: >> 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? There are different pieces of software coming from "big corporations", and there. All I know that, say, authors of editors like VS Code, Sublime, etc, are not afraid to change things from time to time, if their search says it results in a better experience. And I haven't seen many user complaints about that. OTOH, it might very well be a part of their recipe for success. > 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. We are accused either way: we're both not conservative enough on one side, and too conservative on the other. Which judgment to give preference to, is basically a personal choice at this point. Or a strategic one. It's an old disagreement, but I think it should be fairly obvious that if we fear to cause discomfort to even one veteran user, we won't be able to achieve much progress. And it's not like the question here it to change a lot or bindings, or a significant/popular one. >> 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? It is a question of which is a better/more consistent behavior. >>> 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. Just like that TAB binding was a bit alien to the state of the Xref UI as it was 4 years ago, that binding will probably be as well. But you can also interpret it like "complete the current action". Icomplete has that binding, but lisp-interaction-mode has eval-print-last-sexp, which is vaguely relevant too. It's not a perfect parallel, but I think 'C-j' is better for this purpose than TAB, and also better than 'q' or 'b'. On the subject of grep-mode, it could have a similar command introduced too, for situations when you only needed to find one occurrence, to jump to it and quit the window. > 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. 'C-c C-c' usually acts on the whole buffer contents and does not depend on point, I think. It might also conflict with the potential "inline editing" feature if/when we get that into Xref. Though it could use 'C-x C-s', *shrug*. To be clear, I'm not wedded to 'C-j', and open to other options. We could even make xref-quit-and-goto-xref unbound, except in xref--transient-buffer-mode-map. Which is the most "completion-like" version of Xref UI we currently have anyway.