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.

[vinistock]

Thank you for the fix! Before we move forward, can you share which editor you are using? Is it VS Code or some fork?

I ask because I can only reproduce a few of the issues you reported and I suspect some of it may be related to the fact that we have special handling for VS Code in order to apply snippets (which is not supported by every editor).

With the increase in number of VS Code forks, we probably need to add some sort of capability on the extension side, so that this becomes less coupled with VS Code itself, but rather any editor that is using our extension.

In particular, I can't reproduce the first scenario for breaking def somemethod. That works fine for me. And I also can't reproduce breaking the if statement, that one also works on VS Code. So I'm wondering if there's actually more than one issue at play

[stathis-alexander]

Thank you for the fix! Before we move forward, can you share which editor you are using? Is it VS Code or some fork?

I ask because I can only reproduce a few of the issues you reported and I suspect some of it may be related to the fact that we have special handling for VS Code in order to apply snippets (which is not supported by every editor).

I'm using pure VSCode (no forks). Let me see if I can come up with better instructions to reliably reproduce. Will follow up here soon, maybe after the holiday.

[stathis-alexander]

@vinistock Appreciate the patience here. I was able to reproduce some very strange behavior. I've included a video here. https://www.loom.com/share/b51cc02ac3f94fe9ada940796e2db111?sid=26fd66a9-03f9-4253-a25d-de35567fc88f