Read query from file

[bheylin]

I would like to be able to read a tree-sitter query from file so I can develop the query in a text editor and optionally save the for a longer time.

So given the query file find_mods_nested_in_test_mods.scm:

; saved in `find_mods_nested_in_test_mods.scm`
(mod_item 
  (visibility_modifier) 
  name: (identifier) @mod.name 
  body: 
    (declaration_list 
      (mod_item name: (identifier)) 
    )
)
(#eq? @mod.name "test")

I would like to be able to give that file to the --rust-query option:

srgn --rust-query find_mods_nested_in_test_mods.scm

---

I`m open to implementing this feature myself, but want to discuss it first.

[issuedigger[bot]]

The most similar issues to this one are:

1. 137 , with a similarity score of 0.91.

2. 106 , with a similarity score of 0.91.

3. 76 , with a similarity score of 0.91.

[alexpovel]

Hi @bheylin , thanks for your request. Apologies for @issuedigger , it's a tool I'm experimenting with and safe to ignore.

Your proposal looks good, it's a useful feature. Your contribution would be very welcome!

I was thinking, should --rust-query be multi-modal and first check if its argument is an existing file (path), if not fall through and see if it's a parsable query (it only does the latter currently)? Or should there be a new argument such as --rust-query-file, so things remain unambiguous?

Valid & existing file paths are nothing like tree-sitter queries, so I reckon multi-modal is safe and sane.

[bheylin]

Hi @alexpovel changing --rust-query and related options to multi-modal also sounds reasonable to me. I would simply use std::Path::is_file on the option's value and branch from there.

I'll get a PR together when I have a moment over the coming days.

[alexpovel]

Great, thanks! I think CONTRIBUTING.md should contain everything you'll need to get started, but let me know.

One thought: the docs of std::Path::is_file mention:

When the goal is simply to read from (or write to) the source, the most reliable way to test the source can be read (or written to) is to open it. Only using is_file can break workflows like diff <( prog_a ) on a Unix-like system for example. See fs::File::open or fs::OpenOptions::open for more information.

which I tend to agree with. So perhaps just opening directly is a more suitable approach.

srgn also uses logging, which we should use to keep users informed of what decision was taken at every step.

The main function of interest should be:

https://github.com/alexpovel/srgn/blob/42349250c580707deea8383fd40f7a0c0b6979eb/src/main.rs#L800-L843

which contains a really nasty macro, sorry... I'm open to any refactors there.

[bheylin]

One thought: the docs of std::Path::is_file mention:

When the goal is simply to read from (or write to) the source, the most reliable way to test the source can be read (or written to) is to open it. Only using is_file can break workflows like diff <( prog_a ) on a Unix-like system for example. See fs::File::open or fs::OpenOptions::open for more information.

which I tend to agree with. So perhaps just opening directly is a more suitable approach.

Yea that's a fair point, I'll update the proof-of-concept code.

srgn also uses logging, which we should use to keep users informed of what decision was taken at every step.

:+1: