bug#61017: 29.0.60; ruby-ts-mode indents class between two lines incorrectly

[Aaron Jensen <aaronjensen@gmail.com>]

On Tue, Jan 24, 2023 at 1:53 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 24/01/2023 16:17, Aaron Jensen wrote:
> > On Mon, Jan 23, 2023 at 4:28 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> >>
> >> Hi!
> >>
> >> On 23/01/2023 06:33, Aaron Jensen wrote:
> >>>
> >>> Start with a buffer in ruby-ts-mode like:
> >>>
> >>> a
> >>>
> >>> b
> >>>
> >>> Between the two lines, type "class Foo", then press enter
> >>>
> >>> You should get this:
> >>>
> >>> a
> >>>
> >>>     class Foo
> >>>
> >>> b
> >>>
> >>> But this is expected:
> >>>
> >>> a
> >>>
> >>> class Foo
> >>>
> >>> b
> >>>
> >>> Note that reindenting after adding the "end" will indent correctly, so
> >>> it's only an issue with electric indent
> >>
> >> Thanks for the report, the problem here is that such examples parse into
> >> a malformed syntax tree:
> >>
> >>     (program (identifier)
> >>      (ERROR class (constant) (identifier)))
> >>
> >> Another example would be:
> >>
> >>     class C
> >>       def foo
> >>
> >> which parses as
> >>
> >>     (ERROR class (constant) def (identifier))
> >>
> >> We can try to anticipate such cases and infer the implied structure
> >> somehow, or just disable indentation for specific cases. See the
> >> attached patch for the latter.
> >>
> >> Is it enough of an improvement?
> >
> > That seems to make indentation after an open def not happen:
> >
> > def foo
> > bar
> > end
>
> Not sure what you mean. Is that an example with an "open def"? "end"
> seems to be closing it. In the final state, it indents correctly here.

Sorry, that's what I meant. If I do type exactly that and do not
reindent, I end up with that though (closing with the end does not
cause the previous line to reindent)

>
> > I applied the patch manually though, so maybe you can confirm that you
> > see the same thing?
>
> If I have a buffer with just the first line:
>
>    def foo
>
> then it indeed doesn't indent. But I think that happens with or without
> this patch?
>
> It's a slightly different problem: the grammar parses this code example
> without ERROR nodes, like a full method, for some reason:
>
>    (program
>     (method def body: (identifier) end))
>
> And the end position of the "virtual" end node stays at the previous
> line, so our code doesn't know it's inside the method.
>
> I suppose we could add some tricky predicate like (is the previous node
> a method with an "end" child that is 0 characters long), but the grammar
> might change (we should look for any previous reported issues about this
> behavior, or maybe ones that resulted in it), and it only happen this
> way when there is nothing after "def xyz" in the buffer.

I wonder if this is mistaken handling of endless methods? I can't
think of a reason that it would parse like that. Should that be
reported upstream?

> Because in the more common case, like
>
>    class C
>      def foo
>        |
>    end
>
> the last "end" is parsed like the closer for the method, the method node
> spans until it, and the line with "|" indents correctly.
>
> WDYT?