JetBrains/resharper-fsharp

How can I disable auto indent of Rider F#?

MangelMaxime opened this issue ยท 11 comments

Often, when pressing "Enter" Rider tries to auto indent the code but most often than not it goes against my flow of working.

rider_annoying_indent.mp4

How can I disable this feature?

How can I disable this feature?

I think I would be much better to have it fixed instead of disabling. ๐Ÿ™‚

Thanks for writing about it, this is a good example of where the logic isn't good now. We should definitely fix it. Can you share any other examples, so we could take them into account as well?

I will for sure report them, right now I can't seems to find them. But I think indeed there are others places.

Because, I against fight against Rider which is unfortunate.

I would still love having the capacity to choose what is enable or not, especially when the editor try to be smart like auto indent, auto un-indent, code injection, etc.

But I think this is a personal preference.

There is also this situation:

indentation_1.mp4

In theory, the cursor does indent correctly but the problem is I have to un-indent the ).

I am not certain what behaviour we expect here. Does Rider un-indent code sometimes? If yes, should he un-indent the ) if I add a new line?

@MangelMaxime Thanks for this case, I've been thinking about it for some time now.

I am not certain what behaviour we expect here. Does Rider un-indent code sometimes? If yes, should he un-indent the ) if I add a new line?

It could also be that after adding a new line you'd write another expression:

fun1 (fun options ->
    doSomething()
    doSomethingElse()
)

The idea here was it's better to require one manual deindent on the closing paren than having to reindent on each subsequent expression.

Do you always place the closing paren this way? Even in pipes?

a
|> Foo (fun x ->
    123
)
|> Bar (fun y ->
    123
)

If yes, we could try changing the behaviour with a Fantomas/R# setting. Do you use Fantomas on this solution? If yes, have you changed any settings?

Do you always place the closing paren this way? Even in pipes?

When writing the code manually, yes I always place the closing paren this way.

a
|> Foo (fun x -> 123) // If I put everything on the same line, then I keep the paren on the same line
|> Bar (fun y ->
	123	// If I add even 1 new line in the function body then, I keep the paren on a new line to keep a visual consistency 
)
|> Baz (fun z ->
	doSomething ()
	doSomething ()
	doSomething ()
)

I do use Fantomas and I have fsharp_multi_line_lambda_closing_newline=true among other settings to try making follow my way of writing code.

Full setting list:

[*.{fs,fsx}]
fsharp_max_record_width=0
fsharp_max_array_or_list_width=0
fsharp_multiline_block_brackets_on_same_column=true
fsharp_bar_before_discriminated_union_declaration=true
fsharp_experimental_stroustrup_style=true
max_line_length=120
fsharp_multi_line_lambda_closing_newline=true
fsharp_keep_max_number_of_blank_lines=1

I do use Fantomas and I have fsharp_multi_line_lambda_closing_newline=true among other settings to try making follow my way of writing code.

Great, thanks! It allows us to see what kind of style is expected here. I'll try using it in the Enter logic, so this example:

a
|> Foo (fun x ->{caret})

would become

a
|> Foo (fun x ->
   {caret}
)

when pressing Enter.

@MangelMaxime Both issues are covered in 2022.3, could you try the EAP builds and see if there're any additional cases where it doesn't do what you expect?

Thank you @auduchinok for the notification.

I will try to find some time to experiment with in the following days.

@auduchinok I think the first problem I reported is not fixed yet.

rider_indent_report_problem.mov

In the second function I don't think the indent should happen because the code is already indented compared to the let position.

@MangelMaxime Thanks for checking it.

In the second function I don't think the indent should happen because the code is already indented compared to the let position.

Is uses the indent defined below. I agree that, at least if there was no async expression below, it should've not added the additional indent.

The previous examples had = on a new line, and this one does not. I should also consider cases like this, but that would require working with the parser tree instead of the lexer, and I'm a bit afraid there may be cases where parser recovery isn't good enough for this to work reliably. I should try, anyway ๐Ÿ™‚

Is uses the indent defined below. I agree that, at least if there was no async expression below, it should've not added the additional indent.

You are right indeed. I checked and if there is no async the indent is correct.

Unless, you want to work on something else I think we can close this issue. I will open a new one if I find another case.