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: Wed, 28 Jul 2021 03:08:27 +0300 Message-ID: <7593e0f3-9399-ccf3-21de-b2ac79ae3730@yandex.ru> References: <030dbe6c-130d-e578-f50d-54e90bfa7cfa@yandex.ru> 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="36388"; 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: 49731@debbugs.gnu.org To: Daniel =?UTF-8?Q?Mart=C3=ADn?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 28 02:09:11 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 1m8X8I-0009KM-Ua for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Jul 2021 02:09:11 +0200 Original-Received: from localhost ([::1]:60156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8X8G-0001xn-Si for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Jul 2021 20:09:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53970) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8X8A-0001xa-GS for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2021 20:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42713) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m8X8A-0004M2-9S for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2021 20:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m8X8A-0002Yi-3l for bug-gnu-emacs@gnu.org; Tue, 27 Jul 2021 20:09: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: Wed, 28 Jul 2021 00:09: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.16274309219806 (code B ref 49731); Wed, 28 Jul 2021 00:09:02 +0000 Original-Received: (at 49731) by debbugs.gnu.org; 28 Jul 2021 00:08:41 +0000 Original-Received: from localhost ([127.0.0.1]:54259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8X7p-0002Y6-C6 for submit@debbugs.gnu.org; Tue, 27 Jul 2021 20:08:41 -0400 Original-Received: from mail-ed1-f51.google.com ([209.85.208.51]:35550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8X7j-0002Xm-8L for 49731@debbugs.gnu.org; Tue, 27 Jul 2021 20:08:39 -0400 Original-Received: by mail-ed1-f51.google.com with SMTP id u12so803492eds.2 for <49731@debbugs.gnu.org>; Tue, 27 Jul 2021 17:08:35 -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=0e6yjSUHVGysWSeXWq27HvKLsFuBob+DXfif/P09K3c=; b=ZhdsiFjdgbVdrZOnwlnipdRBl5a/tRGBRXRdErravyVX/o31V38PcyLESam9aYK/gx yI5/HAnTvGGoVsIf4XD09U4fyJCrXBhAEwrWTJEbl+45oJ4jSFywbFzQSUt11xwXV5Ei UQ1ciWJyfBgrSCVszIg1EdbIdSRodLib4hSgUUD7DvzmA0WHn3VbMQHcjsY81uwaU1zH cMOeKJOo3mpBNkw+5WulAh5IPHSmpwwaHEjG5MoDJxtjHEqaG5rTmYWxAJWi2ar1lyfp 6Uja06k/btrXg8HcBvzVrVN1t/IzUsYTDBobWghnLHeP7gaTYmvCK76IjCQ2zENIWByh 3JNw== 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=0e6yjSUHVGysWSeXWq27HvKLsFuBob+DXfif/P09K3c=; b=lk+xvteq1SW99ayE/GclcmGCdzdh5z5RXk4JXWtEj8c9MPKDDWXlItytJaVvWFzfdR r9ZW1LRNe9gZzCsq6YJoaLP7Y1nSxwrU6zpVD4QHq4DzJgAiW6TCmTsf1dWekQolSauN jlhWDD87gFRo17+domNO5ignme5E575p4PvCto/mJm9JBElYMempI02XZ3bF6KjXlwAm HgUJARsN3HtwRgXyfXaiGhiT5zoNUa4wXxZjMJtjvxgLgQDBRTI74Y11LMk7uZiZHL3P zXJSrSchPlyz2Hiuaus1xVUx0kptRrhAESskD8r4SuWeDw3qy3oEAgRuoUa7108Xhthe ejOw== X-Gm-Message-State: AOAM533tvT/eSnshwaO2oNmj7q+8VnUAfhTE6EFuKYl/jYzzwK7tXh1w LqD7NMMG+14Kls7ikoFFbBrcNtjDTgk= X-Google-Smtp-Source: ABdhPJyY1FxC2SOjfspxcWTG3ORg2ay5zwTiO+s/a+KF1qFyLV+OrFFhX5Algu8xpLaVJt876V1btQ== X-Received: by 2002:a05:6402:1546:: with SMTP id p6mr30755361edx.206.1627430909376; Tue, 27 Jul 2021 17:08:29 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s3sm1376929ejm.49.2021.07.27.17.08.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 17:08:28 -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:210812 Archived-At: On 27.07.2021 20:08, Daniel Martín wrote: >> 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. > > I think that kind of search scoping in advance can be specially useful > when you are doing a grep-like search in the codebase, using either > grep, rgrep, project-find-regexp, or xref-find-apropos. > > I see it less useful for example when you place the point in an > identifier and press M-?. You'll want to see all the references first, > and then filter afterwards if they are too many. But I think it's a > matter of personal preferences and different workflows. Agree on both counts. Except for xref-find-apropos: it usually works more similarly to xref-find-references. Ultimately we should get both options. >> 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. >> > > Yes, that's the direction that interests me the most, if it's actually a > worthy feature for Emacs users. I'm fairly certain there is a demand for this kind of functionality. >> 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. >> > > I didn't have in mind implementing cumulative filters. I don't know if > people would need such advanced filtering of results. FTR, I've > researched how other tools and IDEs implement this feature, which is > less common than what I initially thought: I'm fine without that feature, or at least with it not being present in the first version (someone else could add it later, maybe as a separate command). But if the filter is being replaced rather than added to, it's better we make that obvious. For instance, by putting the previous filter as initial input when the user invoked the filtering command a second time. > <...> > > - Chromium Code Search: It offers a box to filter by file path. It also > offers an option to exclude tests and generated files. The ability to exclude or include certain categories of files (like generated ones and ones listed in .gitignore) seems to belong to the option 1 -- better executed when we have more information about the current project, which when the Xref buffer is rendered is mostly lost. >> 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. > > Here's a first quick and dirty prototype based on Juri's code snippet: It works, which is a good thing. Though it overrides the existing 'q' bindings (now you can't quit the Xref buffer). But do we want it to be implemented using outline-mode? Because we want the corresponding visuals? Because otherwise a dedicated implementation shouldn't take much more code either (probably roughly the size of xref-truncation-width feature we added recently). Speaking of 'f' and 'q', do we have a precedent for this kind of interaction somewhere else in Emacs? I'm not against those per se, but I'd really rather we try to follow one of the existing workflows, so that the users wouldn't have to remember yet one more thing. Hence the idea from package.el. Or yet another approach: tack the ability to cancel the filter on top of a search history feature (accessed with C-c C-b/C-c C-f, like in Help buffers). But we'd actually need to implement that feature first.