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 14:14:30 +0200 Message-ID: References: <87k0up68e4.fsf@mail.linkov.net> <99772eb6-5a4e-7cf6-259d-0e9429e6bf97@yandex.ru> <878sb3n0a9.fsf@mail.linkov.net> <48f942f9-a557-0185-25fe-612e78cd9071@yandex.ru> <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> <878s9o1ck2.fsf@mail.linkov.net> <837dp7q3hi.fsf@gnu.org> <2e07d6d1-5a83-77c3-7915-8efa46fd47c3@yandex.ru> <83h7oanxoi.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="25801"; 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: juri@linkov.net, 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 Fri Dec 25 13:15:22 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 1ksm0A-0006cH-30 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 13:15:22 +0100 Original-Received: from localhost ([::1]:43254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksm08-0007R5-Ji for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Dec 2020 07:15:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kslzr-0007Qs-Ip for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 07:15:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45365) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kslzq-00033u-AN for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 07:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kslzq-0008Vt-6B for bug-gnu-emacs@gnu.org; Fri, 25 Dec 2020 07:15:02 -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 12:15: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.160889848532685 (code B ref 44611); Fri, 25 Dec 2020 12:15:02 +0000 Original-Received: (at 44611) by debbugs.gnu.org; 25 Dec 2020 12:14:45 +0000 Original-Received: from localhost ([127.0.0.1]:56911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kslzZ-0008V7-5U for submit@debbugs.gnu.org; Fri, 25 Dec 2020 07:14:45 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:55615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kslzU-0008Uq-6D for 44611@debbugs.gnu.org; Fri, 25 Dec 2020 07:14:44 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id c124so3530918wma.5 for <44611@debbugs.gnu.org>; Fri, 25 Dec 2020 04:14:40 -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=UVnkfLBcrJ//MFJRY0eKD3I8YRfD9u/N2eS2QmcV/Y4=; b=NK7H4bBXvK9BbFkz5NQ5a75zuNl/8vM0XEUkNw9jBbFbe0nwByq+3yQxXevIibzeDN XkRFYLxV+VuaGgwgqLyXr/GY5tGp0zJaVR9atIv1MJUmVhG9YWE0Q5JJ//cZcMvmiLZF raQRfmA6go3R9PzOBtnunUSTBkak4R3PiveJJJyP/ncObY8D40cZC4+GfdzDazFJFQQT KN9gp/RlsysksOKVBLOxANkKoNg7keVfh0vcC03dNTeq6WJVvmmoFZ2B2jhsNheA62UE J+yyKzs1kSUivvjVhbccKXUEELh9B9w5DLBOSJwfakHKUI6Zwgvi95nf6EpujNFYpAEv BRIA== 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=UVnkfLBcrJ//MFJRY0eKD3I8YRfD9u/N2eS2QmcV/Y4=; b=HIFWsDE25gpJ8kRHiZg9dm79Qkg4dFAHBPVM+QNvDlepjN5n/30QMZ5GaJvoSxclKZ yM9GopuR8hLp32FSWYgkyLUBYPFQQZtMOfyDI2pI0iKFc9zxwKz7Pns60QAQiDlfejpp NBqCXUKPquR5i2a5kFzO7KklLs60uvfRdv/VgS3OcoFMEJ5EIlDSn5b4nuHgRCe8FDDh Sc/JcQ3v6Z/PAgNH6nufYMVvubUTYkQDQfsmJDMWPH5up52yVNjiaRne9c0yKeDNdNp9 t/IG6tvBs+RAn5gOjgRIn5Xd1e/iWsNQGp6lYd9sRA20U8IQOoUqOJ2YOVJ/VSRRYGbP FlPQ== X-Gm-Message-State: AOAM532BCAvoVrwA+eYicHanw5+wFNFA3tNmTokh8ikjJNL40xobTSRN pg9paqHvoraAXz/OkT2/edQl+IqlEeKs5A== X-Google-Smtp-Source: ABdhPJzLbrg07NSPQC7krVCSN3C2QRw+oeNhBFQifac3WeflsqlVWBJzCjYZWukyvYTkpTpPor0LDA== X-Received: by 2002:a1c:234d:: with SMTP id j74mr8425495wmj.18.1608898473647; Fri, 25 Dec 2020 04:14:33 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k6sm7732595wmf.25.2020.12.25.04.14.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Dec 2020 04:14:32 -0800 (PST) In-Reply-To: <83h7oanxoi.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:196699 Archived-At: On 25.12.2020 09:37, Eli Zaretskii wrote: >>> Why does project-find-regexp need to use Xref for displaying the hits? >>> why not use Grep-like display we use in *grep* buffers? >> >> These days the default Xref buffer is pretty much Grep-like. Certainly >> much closer to grep-mode than it had been in the first versions. That >> old UI was a lot more completion-like in its behavior. >> >> This happened gradually, after we have addressed feedback from you and >> other users, so that xref-find-references and project-find-regexp behave >> more in a fashion that you would expect from it. And those >> expectations were surely informed by Grep and other built-in modes. > > Then why do we need to have 2 separate modes? Well, Grep (and similar major modes people wrote in third-part packages) do have a certain advantage: its execution is asynchronous, and the user sees the results as soon as they arrive, even during a search over a huge number of files. This can be implemented for xref, with certain changes in the API, and with some use of threads, but that's still a research problem. Grep also has less computational overhead. I have spent quite some effort to reduce the gap, and xref works fine for me in that regard, but with the amount of user feedback I/we generally receive for improvements in core features (i.e. close to none) I can't be sure whether there are people who avoid 'M-x project-find-regexp' because Grep feels faster anyway. > Are there any plans for > replacing grep-mode with xref-mode in all the commands that use the > former? I think we'd need a more concerted effort for something like that, rather than just myself. To get such volunteers, making the current Grep users even more satisfied with the current state of xref--xref-buffer-mode is a good step, with much upside and really no downside (at least to a point where we'd have to compromise on the design). I can outline a possible roadmap for improving xref, making its code structure and data more logical (which includes moving some of them out), but I don't think we'll throw out 'M-x grep' away anytime soon. Changing the latter to use the xref UI (which will have to be renamed and become a separate package, BTW) is also likely to encounter much bigger resistance than anything we've done in this area before: people don't have the same expectations for new commands as they have for existing ones, so I'm surprised you asked this (given your overall backward compatibility stance, much stronger than mine). But we can try. Up until now, we've been using xref mostly in places where there its programmatic interface is a strong advantage. > Do we also want to replace compilation-mode with xref-mode? That wouldn't work. It's possible to write a similar alternative for compilation-mode, but that would be a different project. It could reuse some ideas, though. > If the plan is to make such replacements, that could be a good idea, > and we can discuss the roadmap towards that goal. Such a roadmap > should include a transition plan that will help people migrate as > painlessly as possible, including the key bindings and the somewhat > different looks. It's a big change, one I'm not at all confident we could manage before Emacs 28 is released. Do you really want this to happen, though? I never got the impression that you enjoy using xref. > And perhaps _then_ we will have a good enough reason > we don't have now to rebind xref-mode's TAB in Emacs 28. Let me get back to that in another subthread.