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#49731: 28.0.50; Filter xref results by filename Date: Tue, 27 Jul 2021 02:28:58 +0300 Message-ID: <030dbe6c-130d-e578-f50d-54e90bfa7cfa@yandex.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19794"; 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 To: Daniel =?UTF-8?Q?Mart=C3=ADn?= , 49731@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 27 01:30:14 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 1m8A34-0004yU-2X for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Jul 2021 01:30:14 +0200 Original-Received: from localhost ([::1]:55592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8A32-0003sM-3V for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jul 2021 19:30:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51540) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8A2s-0003rs-Rv for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 19:30:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40197) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m8A2s-0006Vu-G2 for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 19:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m8A2s-0003cT-3k for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 19:30:02 -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, 26 Jul 2021 23:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49731 X-GNU-PR-Package: emacs Original-Received: via spool by 49731-submit@debbugs.gnu.org id=B49731.162734215013833 (code B ref 49731); Mon, 26 Jul 2021 23:30:02 +0000 Original-Received: (at 49731) by debbugs.gnu.org; 26 Jul 2021 23:29:10 +0000 Original-Received: from localhost ([127.0.0.1]:51743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8A21-0003b2-Jd for submit@debbugs.gnu.org; Mon, 26 Jul 2021 19:29:09 -0400 Original-Received: from mail-ej1-f53.google.com ([209.85.218.53]:43853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8A1z-0003an-4j for 49731@debbugs.gnu.org; Mon, 26 Jul 2021 19:29:08 -0400 Original-Received: by mail-ej1-f53.google.com with SMTP id ga41so18951614ejc.10 for <49731@debbugs.gnu.org>; Mon, 26 Jul 2021 16:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XYQWd3ERxuI9e5RqDqIzjTu3uS9wtvmFKu4f60IiwGE=; b=L7zCAg3ODKejZ0tYnwYh668KF4DYRz/EuB9da6na6QB8ailOtXCKtiI8QsF3w1gkfX BLXQJox/A4GaLvdThqhZO97Ig6Re2BmPE7aRfgaQ348W2BrtoflXCSMPDsnh4ezZWxEA n4lfDbGfWjZPPegoqu4ERt0GdW+rip5e8gftIO4k5MXOTkcOdswfBDxL4Qs+hq7gGHRm 4Avw7By06V8eELngh+w+iyXmGx10VJC48kddBRgvrOxomD4brak15SVVBouwTa+OIuae 0wDw1biMI1sUyou3dEGplzfBlkjPDlKmwooqXW4e/8skAjKB16NkJQ4vSQsRXh0h5tlK UReg== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XYQWd3ERxuI9e5RqDqIzjTu3uS9wtvmFKu4f60IiwGE=; b=aGGSVMd2e1DFpd1KSPVuNEEHJARWpGt7oV6K0Y3cRm5rDXtRQKDAdghHBPQRkEfVfj BzR26jWeUy6g5gKQaM9lLXLkOvr139URo+W3TbUbGtXyDC5L7AsWQwnhd+u6Es5Vmd7E nG0Zm6J3GSQI9NX2/s4TnojdZdQUrfnSsQe/1C9GpxIfVY33eUhRG2PS3JOPBKSgGyOD EY75gzAqzn6uQ0eQ32Gq15/9UQwfaHRO0UDV0Jt/+xXMKwb7FYrFJmgBqqxall66oZZU o6ttipNDFLAhiEKA+9mDEupAQGiCc25AENzg9iw/n/RVaje2J8L6u+gw5Azdm5hgpNmT 61pA== X-Gm-Message-State: AOAM531I+82yCyO8dNqhQhmx4rKC7m6anif99/+cfFxo6oPjcr3dYbGM kMwODXBEoNrgwIV+wgQgg+UcqAT5pPw= X-Google-Smtp-Source: ABdhPJwsh48JTKRZrsK5V8QMxoRcu4/MrK/T7NUcftgQkCIXjJWHRb2NM5ObwZz7G6xbcfA5vjiSBw== X-Received: by 2002:a17:906:c831:: with SMTP id dd17mr13860243ejb.143.1627342141263; Mon, 26 Jul 2021 16:29:01 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h8sm325512ejj.22.2021.07.26.16.28.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 16:29:00 -0700 (PDT) In-Reply-To: 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:210775 Archived-At: Hi Daniel, On 25.07.2021 11:19, Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > > I plan to implement a new feature for xref, but I'd like to get some > opinions first: > > Sometimes an xref backend returns a lot of results spread over several > files. This usually happens in huge projects and for certain operations > like "search references". To make them more manageable, I propose a new > command that can filter xref result groups (typically filenames) by a > regular expression. A user could filter by "tests/", or something like > that, to only get results from unit tests. If you want to see a similar > feature in action, go to > https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/background/background_contents.cc;bpv=1;bpt=1 > and type on "Type to filter by file path", under the "References" tab. This is going to be quite welcome. > Right now the only approach I know for this use case is to use Isearch, > but Isearch searches the entire xref buffer, including xref matches. > > What do you think about this new feature? Do you have any suggestions > about how it should work? We've discussed this sort of functionality before. Here are some approaches (not mutually exclusive): 1. Add the possibility to add filtering by file names, types, etc, before the search is done. This should fit 'project-find-regexp' well. I can point you to a previous discussion with some ideas. The main upside is you can speed up the search. And store such settings as a history. 2. Filter in the resulting Xref buffer. The best part is it can work with the output from any command that uses Xref. The "filtering" is temporary. I'm assuming this is the direction you want to work in. 3. Do some sort of "editable Xref buffer" feature where you can kill the lines you don't want to see/use, with an undo history. This would probably fit better together with another requested feature (wdired-like editing). I've never exactly considered the option 2., but I'd be happy to talk the details. WRT UI, maybe something along the lines of package-menu-filter-* commands, bound inside a '/' prefix. One command could add "inclusion filter", another - "exclusion filter", and the third one - reset all filters. '/ /' be bound to the last one. The 'q' binding sounds iffy to be in that regard. Another thing to keep an eye out for - is how the filtering will affect n/p navigation and the xref-query-replace-in-results command. I think they should respect the filtering as well.