New indents in Visual D not tab aligned

[Rainer Schuetze via Digitalmars-d-ide]

On 15.09.2017 10:54, Joseph wrote:
> On Friday, 15 September 2017 at 06:36:26 UTC, Rainer Schuetze wrote:
>> Not sure what the best compromise is.
>>
>> 1. current state: delegate body is aligned to function argument list, 
>> but that makes it unaligned to other code.
>>
>>     int x = foo(123, ()
>>                 {
>>                     return 7;
>>                 },
>>                 2);
>>
>> 2. use next tab-stop for opening brace: no longer aligned to other 
>> function arguments, and even less space available to the right.
>>
>>     int x = foo(123, ()
>>                    {
>>                        return 7;
>>                    },
>>                 2);
>>
>> 3. indent just once from the actual statement, e.g.
>>
>>     int x = foo(123, ()
>>         {
>>             return 7;
>>         }, 2);
>>
>> 4. not indenting the opening brace at all, e.g.
>>
>>     int x = foo(123, ()
>>     {
>>         return 7;
>>     }, 2);
>>
>> this already happens right now if the opening brace is not on a new line:
>>
>>     int x = foo(123, () {
>>         return 7;
>>     },
>>                 2);
>>
>> Notice the ugly trailing argument, though. Cases 3 and 4 have the same 
>> issue.
>>
>> I guess you would expect case 2?
> 
> Yes, it must be 2. Why?
> 
> case 1: It is not indented at all and so cases problems with 
> indentation. e.g., Hitting tab to add a line will result in a line that 
> is indented which is not aligned to code added originally. This ends up 
> in a very screwed up alignment where some of the code is indented to 
> tabs and some to the "delegate". This is what Visual D seems to be doing 
> now and it requires me to fix all the code.
> 
> case 2: This is aligned to tabs and so is "correct". Sure the block is 
> not aligned to the "delegate" but it is as close as it can be, so one 
> gets tab alignment and something that is visually close to the 
> delegate.  The tab alignment overrides the delegate because of the 
> issues that case 1 has.
> 
> case 3: Looks a bit too extreme and difficult to associate the delegate 
> with the actual block. No reason to go this far when case 2 is close to 
> case 1 and gets the tabs correct.
> 
> case 4: Even worse than 3.
> 
> 
> We want case 1 because it associates the delegate with it's block in a 
> visual way(quick to see) but we must still align to tabs(case 2) because 
> the IDE is not smart enough to always make sure we are properly aligned 
> when inserting new lines and such. So, the safe side is case 2 which is 
> about the best one can get IMO. Case 3 and case 4 are just further away 
> from case 1 so it makes it even more difficult, and I see no point in 
> even considering them.
> 

Just tried it with C++ and C# in VS2017: smart indent proposes case 4. 
Reformatting in C++ enforces it again, while C# more or less keeps 
whatever indentation you have applied manually. I agree it's ugly, though.

A minor alternative to case 2 would be to keep the braces aligned to the 
parameter list, but indent the first statement to the next tab stop, e.g.

      int x = foo(123, ()
                  {
                    if (cond)
                        return 7;
                    return 3;
                  },
                  2);

This could be applied everywhere, i.e. an opening brace would no longer 
cause an indentation by the tab size, but to the next multiple of the 
tab size.