New indents in Visual D not tab aligned

[Joseph via Digitalmars-d-ide]

On Friday, 15 September 2017 at 06:36:26 UTC, Rainer Schuetze 
wrote:
>
>
> On 15.09.2017 00:48, Joseph wrote:
>> On Wednesday, 13 September 2017 at 20:53:09 UTC, Rainer 
>> Schuetze wrote:
>>>
>>>
>>> On 13.09.2017 06:03, Joseph wrote:
>>>> In Visual D, when I create a new indentation with smart 
>>>> indents enabled, such as starting an inline lambda, the 
>>>> indentation is not tab aligned, requiring me fix it 
>>>> manually. If I forget then everything is off and difficult 
>>>> to fix.
>>>>
>>>> It seems that indention in Visual D does not obey tabbing 
>>>> when smart tabs are set. I'm not sure if it is the general 
>>>> case, but it generally always seems to add 2 spaces, which 
>>>> throws everything off by 2 spaces.
>>>>
>>>> Could this be fixed?
>>>>
>>>> Thanks,
>>>> Joseph
>>>
>>> I don't see any problems. Could you provide a concrete 
>>> example? What VS version do you use? What are your tab/space 
>>> settings? Virtual space enabled?
>> 
>> Really?
>> 
>> When you type something in like
>> 
>> void foo(()
>> {
>> });
>> 
>> (the new lines are enters, the ide should indent the { and 
>> });) that the { and }); are aligned to tabs?
>> 
>> When I do that they are not. When ever I hit enter and a smart 
>> indent is made automatically for me, they are not tab aligned 
>> but have extra space.
>> 
>> it looks something like this
>> 
>> |    |    |    |    |  <- tabs
>> void foo(()
>>              {
>>              });
>> 
>> In fact, here is code copied from the editor when I enter the 
>> above:
>> 
>> |   |   |   |
>> void foo(()
>>           {}
>> 
>> So is one space off.
>> 
>> If I use fo instead of foo, it is aligned, just because `void 
>> fo(` is 8 chars or 2 tabs. Visual D seems to completely ignore 
>> aligning to tabs and instead uses some other logic that isn't 
>> appropriate.
>> 
>> 
>
> Ah, I see now. This happens when the delegate literal is passed 
> as an argument to a function. The opening parenthesis forces 
> the indentation to align to the right of it.
>
> That's not always perfect, as there can be little space left to 
> the right, so other formatting styles just indent arguments a 
> single tab.
>
> If you put the opening brace in the line of "()", the body 
> statements are just indented a single tab.
>
> 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.