emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: treesit indentation "blinking"


From: Dmitry Gutov
Subject: Re: treesit indentation "blinking"
Date: Mon, 3 Apr 2023 23:58:17 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]