Visual Studio/D spaces

[Johnson Jones via Digitalmars-d-ide]

On Friday, 11 August 2017 at 06:59:16 UTC, Rainer Schuetze wrote:
>
>
> On 10.08.2017 23:29, Johnson Jones wrote:
>> Hi Rainer,
>> 
>> this is more of a visual studio question but I figured you 
>> might know the answer.
>> 
>> I tend to get quite annoyed by spacing when editing a D 
>> program.
>> 
>> When I have to combine two lines I generally have delete a lot 
>> of white space in between to combine them. I'd rather all 
>> white space be removed.
>> 
>> e.g.,
>> 
>> writeln(x);
>> writeln(y);
>> 
>> and I want to turn it in to
>> 
>> writeln(x, y);
>> 
>> I do this, usually, by hitting delete at the end of the first 
>> line, in which case VS will remove the \n and bring the second 
>> line to the first, but with all the spacing(indentation makes 
>> it worse).
>> 
>> I'd like it to look like
>> 
>> writeln(x);writeln(y);
>> 
>> after the first delete(or so).
>
> Try Ctrl+Delete.
>
>> 
>> Also, when hitting enter to split something(say the above), 
>> visual studio adds spaces rather than tabs and that causes 
>> problems due to mixtures. I despise spaces. Tabs are the way 
>> to go for me, but when mixed, it causes problems because I 
>> always use tabs to indent... and this causes alignment errors 
>> with mixed tab/spaces of other lines.
>> 
>> 
>> I have very simple rules for how I lay out things.
>> 
>> 1. Any space, tab or mixed, is treated as one token for delete 
>> or backspace.
>> 2. All spaces are converted to tabs when more than one space 
>> separates two non-spaces. (I never use __, for example, where 
>> _ is a space.). The formula for space to tab conversion is 
>> floor((tabSize*numtabs + numspaces)/tabSize) + I where I is a 
>> space if the floor value is 0 and would put two non-spaces net 
>> to each other.
>> 3. Enter will always align with previous indentation level, 
>> clamped to a tab. Backspace does the same if the previous line 
>> was empty.
>
> My basic rule is: tabs for indentation, spaces for formatting 
> (e.g. when aligning expressions vertically).
>
>> 
>> These basically treat space as simple visual alignments and 
>> tries to keep everything consistent. There may be a few corner 
>> cases I forgot to list but the idea is pretty simple. It is to 
>> minimize key strokes dealing with alignment/space and single 
>> spaces are only ever used as token separators(and no more than 
>> one).
>> 
>> I implemented these rules before in a vsix but it's been 
>> several years and it was for C# and was somewhat of a hack(had 
>> to work on the edit buffer directly).
>> 
>> Do you know if visual D encode these rules directly? Or does 
>> the visual studio settings accomplish this if set right(I've 
>> never been able to get it to work right)?
>> 
>> Thanks.
>
> Visual D handles (smart) indentation, and you can configure 
> whether it uses spaces or tabs in the Text Editor settings. 
> Other than that it usually doesn't intercept typing white space.
>
> I doubt that your rules are available as preconfigured settings 
> in VS. Maybe this could be implemented in the EditorConfig 
> extension (which I use to switch preferences within different 
> projects).

I guess this might be the reason I can't get tabsanity to work in 
visual D? Works for non D solutions but not D solutions. I 
suppose I can modify visual D to do what I need?

Usually a nice way to debug vsix extension is to add

<StartAction>Program</StartAction>
<StartProgram>$(DevEnvDir)\devenv.exe</StartProgram>
<StartArguments>/rootsuffix Exp</StartArguments>

to the csproj in the first <PropertyGroup>

Visual D is not a vsix though and so I think more work has to be 
done.

Maybe we could set it up to that the visual D files are copied to 
a temp directory(or use the output from the build?) and change 
whatever the experimental VS is looking for when it adds visual D 
to it? (since I think we can't copy the dlls directly as they are 
in use, and probably not a good idea anyways).

Basically a pre-build command that modifies the experimental hive 
to point to that temp dir? That should allow a similar debugging 
experience to vsix extensions.

This way we can use a stable visual D side by side with the 
unstable and we should be able to debug it using "itself". (a 
sort of bootstrap process)

That way, those that actually use visual D for project 
development can use the experimental version and any time a bug 
happens or something needs to be tested, it one can jump back in 
to the stable instance and do what is necessary. (Although, like 
you said, not sure if it will be possible due to the slowdown)


I think to do this, all one needs to do is get the exp to use the 
exp visual D, possibly a registry hack?