Re: Tree-sitter api

[Theodor Thornhill]

Yuan Fu <casouri@gmail.com> writes:

>> Great! I've started work on using tree-sitter provided by Yuan Fu in
>> typescript-mode, and it is working rather well. I'm struggling a little
>> with indentation, but I'm sure it's user error.
>
> I’d love to know how are you struggling, because ideally we’d want the
> indentation engine to be very easy to understand and use. Maybe we can
> improve the documentation or something?
>

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)

This could perhaps be abstracted yet again into a shorthand such as
this:

(scope-openers '("function_declaration" "class_declaration" "try_statement"))

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.

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.


>> Making a feature branch for this would indeed help a _lot_ as setup
>> right now is very finicky. I'll report back any bugs I can find while
>> digging.
>
> So you think there can be any improvements in this regard? (Except for
> moving to a feature branch, of course, that’s already on the list.)
>

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.

Sorry for the long post, hope some of it makes sense :)

Theodor