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.
