handle end when there's content remaining on the line correctly

[stathis-alexander]

Motivation

The current behavior of the automatic end on type is unpredictable and strange. It appends the end in weird spots and leaves the cursor in a strange location.

Some examples:

If there's content on the line, the end is inserted and the remaining content is appended after the new end:

If there's a set of parens and you expand to a newline, it puts autocompletes the end inside the paren:

I encounter this most often when breaking sigs up onto multiple lines

Or when attempting to break up the list of parameters:

Or when breaking up lines with long conditions:

Implementation

The current logic is a little bit mystical to me. I'm not sure why the conditions are what they are, and I couldn't find a reasonable way to tweak it to be more reasonable.

My expectation as a user is that if I hit enter, anything after my cursor on the line should always be appended within the autocorrected end block, and my cursor should be left at the beginning of the new line. There's no other natural behavior here.

The complexity is that there is some odd behavior in the parser or in the other auto-correcting behavior from the LSP itself which causes the lines provided to the handle_statement_end to behave differently.

1. If the next character is not a ), then the current line is what you would expect.
2. If the next character is a ), then the current line terminates at the last position, and the next line is whatever content was remaining on the line before the user entered the newline character.

In either case, the user wants the same behavior - all of the remaining content on the line should occur before the autocorrected end, and the cursor should be at the beginning of the new line they just created.

Automated Tests

I couldn't quickly figure out how to get the existing unit tests to run, but I'm thinking they should all pass first try if they're well written. I'd be happy to add additional unit tests here to test more advanced cases.

Manual Tests

Started ruby-lsp in debug mode. Here are some results from the new code.

Breaking up content:

If there's a set of parens and you expand to a newline:

breaking sigs up onto multiple lines

Or when attempting to break up the list of parameters:

Or when breaking up lines with long conditions:

[stathis-alexander]

I'm looking at #1231 from @vinistock and seeing that there are actually two cases here.

Although I do agree that the existing behavior makes more sense in his case:

foo(proc do )

with this code becomes

foo(proc do 

  end
)

I would argue the case I'm solving for is more typical:

if foo()

becomes

if foo(
  )
end

The proper fix here would actually to be to look back to the ordering of the keyword and the paren and then use that to determine if the next paren should appear before or after the end, but we're getting into some pretty complex parsing at that point which this approach (lines & positions) feels a bit too unsophisticated to handle. The right approach here may to be to actually use the AST and try to figure out what the correct auto-complete is from that representation.