Re: Tree-sitter api

[Theodor Thornhill <theo@thornhill.no>]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

Yuan Fu <casouri@gmail.com> writes:

>
> 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.
>

The wall of text is nice, but for some reason I am still struggling a
little.  I've used the 'ts-c-mode' supplied from the RFC, but that seems
to be a little incomplete.  I'll see if that can work, but I think
there's a caveat here as well: in typescript at least there are lots of
'wrapper-nodes' that causes the relevant parent to be further up in the
tree.  I _think_ 'tree-sitter-parent-until' is interesting here, but I
didn't get it to work yet.

Anyways, I'll play more with it and report.

>> 
>> 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.
>
>

Yeah, I agree.  This is something I can implement myself if it serves a
need.  I'm not either.

>
> 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.
>

I meant that when that specific message is sent inside the
indent-line-function, that makes it look like we got a match for
MATCHER, but didn't match for ANCHOR.  I think though that many of the
cases we don't even have a match for MATCHER.  So the message is a
little confusing.

Just to try to make it even more clear - The MATCHER tries to match the
provided node type at the point where the cursor is located as the user
sees it in the buffer, the ANCHOR does the search to some _other_ place
and returns that indentation.  In the end we add offset to that
indentation.  Is that correct?

>> 
>> 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.
>

Great!

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

This is probably the smartest, yes.


While you're here - I've noticed that tree-sitter in some cases doesn't
handle errors in the AST very well, messing up indentation.  See
provided screenshots for the details.  What happens here is that when I
press 'enter' to add a newline at the top, everything shifts, and the
font-locking is wrong.  If I undo it, it goes back to normal.  If I save
the buffer and revert the buffer, it goes back to normal.  Not sure what
is happening, but maybe we can add a shield to not change font-locking
should the parser return error for some reason?

Or is it returning error because of Emacs sending the wrong thing?

Thank you for your patience.

Theo


[-- Attachment #2: correct.png --]
[-- Type: image/png, Size: 66991 bytes --]

[-- Attachment #3: wrong.png --]
[-- Type: image/png, Size: 65645 bytes --]