Re: treesit indentation "blinking"

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 03/04/2023 15:56, Alan Mackenzie wrote:
>>> That is NOT electric indentation.  The whole point about electric
>>> indentation is for it to take effect whilst point is still on the line
>>> being edited.  Thus, for example, you can see whether or not the line
>>> needs breaking, or whether there's room for a short comment at the end
>>> of the line.
> 
>> Wouldn't you know whether the line needs breaking, as long as the line
>> was indented correctly when you opened it with RET?
> 
> Maybe sometimes, but often not.

I think it's the exceptions that are relatively rare, mostly labels 
(goto and switch/case). I'm no C++ expert, though.

>> This is not a substitute for enabling electric-pair-mode, alas.
> 
> As you've no doubt gathered, I particularly dislike electric-pair-mode.
> I'm likely far from rare in that respect.  I think we'll be doing our
> users a disservice if indentation only works when e-p-m is enabled.

Be that as it may, improving the state of affairs looks difficult. It 
will likely involve taking part in C and C++'s grammars development, and 
even then full success is not guaranteed.

I've tried to make indentation's behavior better in ruby-ts-mode is 
similar circumstances, but the sole difference between it and c++ indent 
rules is that is has a "catch all" rule which, for code like

   def foo
     if asd

, does indent 'if' one level. And Ruby code is usually more nested anyway.

Also note that the C++ example starts working much better as soon as 
there is at least one closing brace, e.g.

int foo() {
   for (;;) {
     |

}

because in this situation both the declaration's bounds and the for 
node's bounds are more or less easily determined.

In practice, it should mean that as long as the top-level definition is 
"closed" (perhaps manually, without electric-pair-mode), you can type 
inside an enjoy much better auto-indentation. Although maybe some 
exceptions will remain still (some further research could be useful).

>> I would also prefer c++-ts-mode supported indentation with closing
>> braces missing, but we're really limited by what the parser provides.
>> E.g. for this code
> 
>>     int foo() {
>>       for (;;) {
> 
>> we get this parse tree:
> 
>>     (ERROR (primitive_type)
>>      (function_declarator declarator: (identifier)
>>       parameters: (parameter_list ( )))
>>       { for ( ; ; ) {)
> 
>> where the "for" statement isn't even present (the separate tokens are
>> parsed as leaf nodes, and that's it). It's difficult to write meaningful
>> indentation rules that would match this.
> 
> Why do we get a parse tree with ERROR in it when the source isn't
> erroneous?  It is merely incomplete.

It is incomplete and hard to make sense of, apparently. But perhaps 
someone could contribute improvements to the parser that would make 
things better.

> Tree sitter was surely designed for
> editors, where source code being entered is typically incomplete, not
> just for things like code formatters.  Why do we not get a full valid
> parse tree indicating the current (incomplete) state?

The parser's tolerance has limits, aparently. But see my latest example: 
that code is still incomplete, and yet it parses much better.

Most code editing is additive, rather writing functions from scratch. So 
I'm guessing it might work out, most of the time.