Add ability to do global search based on tree-sitter grammar

[IvanGoncharov]

I do a lot of refactoring, and I try to do one particular refactoring per commit but across all the repo.
So I frequently write small regexp to find a particular pattern in the source code.
Today I wanted to find all JS exports/imports for local files that don't have '.js'.
I managed to come up with a working regexp only after 5min of trial and error.

At the same time, Helix already has a bunch of Treesitter grammars so why do I need to mess with RegExp anyway?
I never used Treesitter in my life and after reading official docs on query syntax, I managed to write the correct query on the first try:

So my idea is to have a window where you can enter a tree-sitter query and get all the matches across the repo, similar to the window with <space>/ results.

I did a quick google and learned that it not a new idea:
https://github.com/BrianHicks/tree-grepper

But I still think it should be a part of the editor:

1. I want to see all matches in an editor anyway
2. Having to autocomplete for writing tree-sitter queries would help a lot
3. Helix already has all dependencies already (treesitter + bunch of grammars) so I don't need to install one more tool.

Basically, if we already support search using RegExp I suggest offering the same tree-sitter queries.

[the-mikedavis]

I don't think it would be too much work to implement this on the tree-sitter side given what we have for highlights and some of the refactoring in #2857.

The UI for writing queries could use some discussion though. Using the prompt for this (like when searching by regex) seems clunky since meaningful queries are usually long.

Maybe we could pipe a selection? So you would have a selection over a query and then you would use a keybind or typable command to use the query under that selection as input.

[IvanGoncharov]

Maybe we could pipe a selection? So you would have a selection over a query and then you would use a keybind or typable command to use the query under that selection as input.

My ideal workflow would be like this:

1. I work on a file notice part that I like to find across the repo so I select it.
2. I run :global-treesitter-query (just a command, don't think it deserves its own keymap).
3. I get some textarea, buffer, etc. populated with query matching my selection (also should work for multiple selections).
4. If I am ready to execute a query I get picker similar to "global file search" where I can preview my matches.

More details on #3:
To make this feature usable you need some way to get the names of node types and properties.
Without having access to tree-sitter AST I don't know even where to start writing my queries.
At the same time, if I get an AST dump for the entire file it would be too much info for me to process.
What can work is creating a basic query for the selected nodes.

Below are examples where ^ mark selection (I use JS as an example):

import { test } from './test';
 ^
// (import_statement)

import { test } from './test';
                        ^
// (string)

import { test } from './test';
  ^                      ^
// (import_statement 
//   source: (string)
// )

import { test } from './test';
  ^^^^^^^^^                   
// (import_statement 
//   (import_clause 
//     (named_imports 
//       (import_specifier 
//         name: (identifier)))))

import { test } from './test';
         ^               ^
// (identifier)
// (string)

import { test } from './test';
  ^       ^               ^
// (import_statement 
//   (import_clause 
//     (named_imports 
//       (import_specifier 
//         name: (identifier))))
//   source: (string))
// )

This mechanism will allow you to write queries without knowing the AST structure of your programming language but just using a multi-selection feature of Helix.
Also, it will be for arbitrary selection and is pretty intuitive.

So after that, you just need to write predicates and you have a working query.
Even if you don't have an example code with a pattern that you searching for, I would argue that it's way easier to write it in than to guess what the correct tree sitter query would be.

P.S. I'm wondering why my "feature request" was closed and converted to the discussion.
I see a lot of "feature requests" discussed as an issue, so can you please explain the rules of this repo regarding "feature requests"?

[the-mikedavis]

P.S. I'm wondering why my "feature request" was closed and converted to the discussion.

I'd like to use discussions over issues for large feature requests going forward: the issue format is better for items that can be acted on immediately and discussions are better for ideas - especially large ones. This idea needs some discussion and probably some 'stepping-stone' work on the UI so I don't think it's immediately actionable (although I'd love to be proven wrong with a PR ;)

Sadly the GitHub UI is rough when converting issues. I don't mean to imply that this idea is unwanted. Personally I think this idea is quite cool and could probably fit into core (rather than being scoped as a plugin).

[the-mikedavis]

I think this could be a better behavior of :tree-sitter-subtree when using multiple cursors

[IvanGoncharov]

Thanks for the explanation.
Having a wider discussion totally makes sense, especially since, as far as know no other editor implements something like this.