all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Daniel Martín" <mardani29@yahoo.es>
Cc: 49731@debbugs.gnu.org
Subject: bug#49731: 28.0.50; Filter xref results by filename
Date: Wed, 28 Jul 2021 03:08:27 +0300	[thread overview]
Message-ID: <7593e0f3-9399-ccf3-21de-b2ac79ae3730@yandex.ru> (raw)
In-Reply-To: <m15ywv8z2n.fsf@yahoo.es>

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.





  parent reply	other threads:[~2021-07-28  0:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m1pmv6iz4n.fsf.ref@yahoo.es>
2021-07-25  8:19 ` bug#49731: 28.0.50; Filter xref results by filename Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-25  8:32   ` Lars Ingebrigtsen
2021-07-25  8:33     ` Lars Ingebrigtsen
2021-07-26 23:16       ` Dmitry Gutov
2021-07-25  9:10   ` Eli Zaretskii
2021-07-25 14:58     ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-25 20:43   ` Juri Linkov
2021-07-26 11:49     ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-26 22:53       ` Juri Linkov
2022-01-16 18:52       ` Juri Linkov
2022-11-21  7:58         ` Juri Linkov
2022-11-23  8:39           ` Juri Linkov
2022-11-23 14:19             ` Dmitry Gutov
2022-11-23 17:50               ` Juri Linkov
2022-11-23 18:08                 ` Dmitry Gutov
2022-11-23 18:20                   ` Juri Linkov
2022-11-23 18:47                     ` Dmitry Gutov
2022-11-24  7:48                       ` Juri Linkov
2022-11-25  7:35                         ` Kévin Le Gouguec
2024-02-13 16:52               ` Juri Linkov
2024-02-14  9:25                 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-15  7:23                   ` Juri Linkov
2021-07-26 23:28   ` Dmitry Gutov
2021-07-27 17:08     ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-27 20:51       ` Juri Linkov
2021-07-27 23:11         ` Dmitry Gutov
2021-07-28  0:08       ` Dmitry Gutov [this message]
2021-07-28 16:12         ` Juri Linkov
2021-07-29  2:02           ` Dmitry Gutov
2021-07-29 17:43             ` Juri Linkov
2021-08-02  2:09               ` Dmitry Gutov
2021-08-02 20:58                 ` Juri Linkov
2021-08-06  0:03                   ` Dmitry Gutov
2021-07-31 16:45         ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-31 17:06           ` Eli Zaretskii
2022-11-23 18:48       ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7593e0f3-9399-ccf3-21de-b2ac79ae3730@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=49731@debbugs.gnu.org \
    --cc=mardani29@yahoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.