Visual D 1.0.0 released

[Petar]

On Thursday, 9 July 2020 at 10:22:50 UTC, Manu wrote:
> FWIW, I actually agree with everything you said about linux as 
> a dev environment vs windows. But that wasn't the question... 
> as an IDE and debugger integration, there is absolutely no 
> comparison to VisualD, not by miles.

While I agree about debugging in VS vs VS Code, I'd say that for 
my use cases VS Code is both a better editor and a better *IDE*. 
VS may come more fully-featured then VS Code out-of-the-box, but 
with its extensions ecosystem VS Code is a better IDE for my use 
cases and I suspect for many other people. Of course, your 
mileage may vary.

> It would be really cool if parts from VisualD were more 
> suitable for
> VSCode, but I can't see that being easy or practical.
> One is the Concorde integration, which is pretty deep, and GDB 
> is just not
> even remotely as good, and the vscode debug UX is embarrassing 
> by contrast.

I don't care about the VS debug engine since it's Windows only. 
Some of the UX may be nice to replicate, but think this falls 
outside big the scope of a dlang editor extension, if said editor 
already has general native code debugging functionality.

Also some people even disagree that VS is better than GDB in 
general: 
https://www.quora.com/Why-is-the-Visual-Studio-C%2B%2B-debugger-much-better-than-GDB-LLDB-or-any-other-debugger-for-C%2B%2B?ch=10&share=b4f38907&srid=3E2D0

Even if if I agree that VS provides a better debugging experience 
than VS Code, GDB is more powerful tool overall, so I don't miss 
Concorde on Linux.

> Then the general autocomplete engine, which is fairly dependent 
> on the
> detail expressed in the project files.

This is false. Most compilers don't work with project files. Same 
for LSPs. All you need is the is the list of all importable files 
and the current active build configuration (what compiler flags 
are set). It is the job the editor/IDE extension to figure out 
the build system or parse through project files. The autocomplete 
engine / the LSP implementation doesn't need to know about that 
stuff.

> Nobody writes VS project files, you generate them, just the 
> same as
> makefiles... nobody writes makefiles.
>

The problem is that there are many things (like MSBuild tasks in 
general) that the VS solution/project properties window doesn't 
allow you to edit effectively, or at all. Yes, the UI may be 
sufficient many/most developers, but that hasn't been the case at 
all for me.  E.g. if you make changes through the UI, like the 
build configurations between x86/x64 and Debug/Release VS ends up 
duplicating large parts of the configuration, while if you edit 
the *proj files by hand you can avoid the duplication and make 
the files easier to read overall. The other deal breaker for me 
is that when the files are in version control I have to read the 
XML anyway in order to track changes. Using the UI to track 
changes to project files is just a nostarter.
So, having had to edit both VS *.*proj files and Makefiles 
manually, I'd say that Makefiles are orders of magnitude more 
approachable and easier for me. MSBuild is just a giant PITA in 
my experience. Though I agree that I don't find Makefiles 
enjoyable either :D, but at least I can more easily track changes 
to them in VCS.