dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.89k stars 784 forks source link

Indentation of certain records, lists is broken by shift+tab #1627

Open csmager opened 7 years ago

csmager commented 7 years ago

Repro steps

Consider a record declaration like this:

type Customer =
    { Id : int
      First : string 
      Last : string }

If I select it and press tab, I get this:

    type Customer =
        { Id : int
          First : string 
          Last : string }

If I then press shift+tab to reduce the indent, I get this:

type Customer =
    { Id : int
        First : string 
        Last : string }

The code no longer compiles, and I have to manually correct the indentation of the First and Last values. The same thing happens with record expressions and creating lists or sequences in a similar way.

Expected behavior

I would expect the alignment to be maintained.

forki commented 7 years ago

I have the same experience in VS but also in VS code.

I assume the text editor thinks it's a C# brace and just tries to indent the open block.

abelbraaksma commented 7 years ago

I assume the text editor thinks it's a C# brace and just tries to indent the open block.

The auto-indent of C# blocks when copy/pasting or tabbing pop on the undo stack. That is, hitting Ctrl-Z just after it happens undoes the auto-layout of the code, but not the edit action (copy or tabbing).

Trying out what the OP writes (I can repro in VS 2015 Upd 3) does not pop on the undo stack, which seems to suggest the cause lies somewhere else.

csmager commented 7 years ago

Having played a bit more, it seems to be that the editor aligns the text for each line independently to the nearest 'tab stop'. Given the default of tab = 4 spaces, the first twos lines are moved back 4 spaces and the remaining lines 2 spaces. If you were to indent each line another 1 space, then the first two lines would be moved back 1 space and the remaining lines 3 spaces.

It appears in the forward direction, the 'offset' of other lines is kept (this is not the case in VS Code where this behaviour is 'broken' on both tab and shift+tab).

It's likely this is simply the default behaviour for VS - having checked, I see the same behaviour in all editors I tried for any arbitrary text. I don't know enough about how this all fits together to know where or how it could be fixed.

daniel-wojcik commented 2 years ago

I'm really disappointed reading it is not planned to be fixed. It is a bug in many dev's opinion: Tab shifts text to the right by some number of spaces and Shift+Tab should do the same but to the left. I would understand if Tab shifted text also in the same manner as Shift+Tab is doing. But now both operations behaves completely different and one isn't reverse version of the other. I also don't understand how many of you - as F# devs - could say everything is ok, while every single space has meaning... I'm really angry every time when Shift+Tab destroys my code and I have to waste time to fix it again and again...

abelbraaksma commented 2 years ago

@daniel-wojcik i don’t see this happening much in everyday coding anymore, yet the problem does persist when using record expressions where the first line uses a half tab. There’s different behaviour depending on whether you have smart tabs switched on or not.

I agree with you, though, that it’d be much better if this were fixed. Luckily it’s open source, so anybody really annoyed by this feature could come in and solve it (unfortunately that hasn’t yet happened in 6 years since this was reported, but who knows!).