Re: Tree-sitter api

[Yuan Fu]

Thanks, your feedback is very valuable.

> I find the way MATCHER -> ANCHOR -> OFFSET technique a little hard to
> parse.  Ideally I'd like to say something like: "Every direct child of
> node FOO should be indented 2 spaces, including the null node".  This is
> the general case of indentation as far as I can tell.  I'm thinking such
> a rule could look like:
> 
> ((child-of-and-null "function_declaration") (node-is "function_declaration") 
> 2)

IIUC, you are thinking about the following, which matches with whatever point 
that is a child of function_declaration and indents 2 columns, is that true?

((parent-is "function_declaration")
 parent
 2)

I am indeed guilty of throwing that wall of text when introducing the indent 
engine. I’ll see if I can make it more approachable. I could probably start by 
showing an example and how to use it, rather than explaining all the details.

> 
> This could perhaps be abstracted yet again into a shorthand such as
> this:
> 
> (scope-openers '("function_declaration" "class_declaration" "try_statement"))

I see what you mean, but that it yet another concept to learn. I’ll try to add 
something like that without adding too much complexity.


> My goal is that I get a typing experience where openers always indent:
> 
> ```typescript
> function foo() {
>  | <-- point is here
> }
> ```
> 
> ```typescript
> function foo() {
>  try {
>    | <-- point is here
>  }
> }
> ```
> 
> ```typescript
> foo(() => {
>  | <-- point is here
> }); 
> ```
> 
> Does this make any sense?
> 
> I find that most of the time emacs cannot find the anchor (that's at
> least what it is logging), and I assume that means it at least matched
> something.

I don’t quite understand. What do you mean Emacs cannot find the anchor? To 
make sure we are on the same page, in a rule (MATCHER ANCHOR OFFSET), MATCHER 
determines whether this rule applies to the current line, ANCHOR tells you 
indent from this position, and OFFSET tells you indent this much from ANCHOR.

> 
> In addition - one trouble I've had with indentation using the libraries
> from melpa is that accumulating offsets in a parentwise path add to to
> too big of an indent.  Here's an example:
> 
> ```typescript
> const foo = someFunction(() => ({
>  prop: "arst",  // <-- indented by two spaces
> }))
> ```
> 
> ```typescript
> const foo = someFunction(
>  () => ({
>    prop: "arst",  // <-- indented by four spaces
>  })
> )
> ```
> 
> This is the expected indentation.  What I'd get is:
> 
> ```typescript
> const foo = someFunction(() => ({
>    prop: "arst",
> }))
> ```
> 
> What happens is that the arguments list triggers as an indentation step,
> but it should only do so when when on its own line.  I believe this is
> what SMIE calls "hanging-p" in its engine.

I think an anchor preset that finds the parent that’s at the beginning of a 
line should solve this. I’ll definitely add that one.

> 
> The hardest part apart from a feature branch is getting hold of the
> definitions.  I think your script-package should be added to elpa so
> that putting them in a directory emacs can see can be automated.
> 
> I _really_ think we should distribute a function to get these libraries
> when emacs ships, as every editor does this.

We thought about it, the main problem is that tree-sitter the library and 
tree-sitter language definitions need to be in sync in terms of version. Since 
Emacs doesn't distribute tree-sitter the library, if we distribute language 
definitions we can’t make sure they are of the correct version regards to the 
tree-sitter library on the system. Dynamic library, being system-dependent, 
isn’t something ELPA can easily distribute either. I can cook up some function 
that automatically downloads language definitions like my script does but that 
feels hacky and incomplete so it isn’t something I want to put into core Emacs. 
Maybe I can put such a function on nongnu ELPA? I’m open to ideas.

Ideally distributions just distribute tree-sitter with all the language 
definitions, and we just use that.

Yuan