Initial work for scopeType matchers based on Tree-Sitter's Query DSL

[Will-Sommers]

Partially addresses #616

I'm considering renaming this branch since it has moved away from a "scheme-scope-demo" and now implements some scopeType matchers for Ruby.

Todo:

• Extract scopeTypes to constants file. Although, is this necessary with @AndreasArvidsson's recent work?
• Add unit test for generation of matchers

Remaining Questions:

• Currently extension path is stored on this.graph, what is the best way to get this down into the nodeMatcher code so we can use it to load queries?
• For range expanding matches which return more than one node, which node should be returned from the matcher? Is this even a concept we want to support?
• Expanding NodeMatcherValue to take either a Tree or SyntaxNode felt like a kludge to me. I'm thinking creating a new v1 interface for this and rolling back the union type, thoughts?

Fixes https://github.com/cursorless-dev/cursorless/issues/436

• [ ] Close https://github.com/cursorless-dev/cursorless/issues/785 if we fix that
• [ ] Comment on #484 saying the process has started and providing link to example
• [ ] Close https://github.com/cursorless-dev/cursorless/issues/797 if we fix that

[pokey]

Shouldn't we use https://github.com/nvim-treesitter/tree-sitter-query instead of scheme?

[pokey]

Also worth mentioning https://marketplace.visualstudio.com/items?itemName=jrieken.vscode-tree-sitter-query, which defines a language id for tree sitter queries

[Will-Sommers]

sg!

[pokey]

As discussed in meet-up, algorithm is as follows:

1. Split range into start and end position
2. For the start position
   1. Find smallest domain that contains or is adjacent to position
   2. If there are two such nodes, pick the one to the right
3. If the end position is contained or adjacent to the domain returned in previous step, return the tagged range
4. Otherwise, run steps 2.1 and 2.2 on the end node
5. If the start position is contained or adjacent to domain returned in previous step, return the tagged range
6. Otherwise, return the range from the start tagged range to the end tagged range, with direction taken from selection

[wenkokke]

I am currently getting compile errors on the head of that branch:

$ tsc -p ./
src/processTargets/modifiers/scopeTypeStages/ContainingSyntaxScopeStage.ts:23:1 - error TS1128: Declaration or statement expected.

23 } from "../../../typings/targetDescriptor.types";
   ~

src/processTargets/modifiers/scopeTypeStages/ContainingSyntaxScopeStage.ts:23:3 - error TS1434: Unexpected keyword or identifier.

23 } from "../../../typings/targetDescriptor.types";
     ~~~~


Found 2 errors in the same file, starting at: src/processTargets/modifiers/scopeTypeStages/ContainingSyntaxScopeStage.ts:23

[wenkokke]

PR to fix the issues in HEAD: https://github.com/Will-Sommers/cursorless-vscode/pull/2

[wenkokke]

@Will-Sommers What is the rationale behind defining all scope types in a single query?

[pokey]

@Will-Sommers What is the rationale behind defining all scope types in a single query?

good question. Having one big query seems to be the convention that other repos are using; see the links in the description of #616. I could see performance being superior if we split it up, but it is easier to have one file per language, esp since most queries are fairly small

[pokey]

Ok this one is good to go, but unfortunately it breaks "every funk" for Ruby. I created https://github.com/cursorless-dev/cursorless/pull/1430 to fix that issue. That PR is ready, so would be great if you could have a look when you get a minute. I think they should prob merge in together so we don't break "every funk" in Ruby on main