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.

On Thursday, 9 July 2020 at 12:06:52 UTC, aberba wrote:
> On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote:
>> On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
>>>
>>> Not really. VisualD is objectively the most functional and competent
>>> IDE/Debugger solution, BY FAR.
>>> It's not an opinion, it's a measurable fact.
>
>> Windows really sucks as a dev environment.
>
> Probably Manu and I are arguing from OPPOSITE sides.
>
> Linux as a dev env in itself contributes to 60-70% of the better-ness over Windows env for development. Its makes sense he holds such opinion since he's on windows...having to rely on Visual Studio for everything. Visual Studio as an IDE is pretty solid though...just not for everyone.

Yep.

> Nevertheless VS Code is pretty good for development. Its not an IDE BTW. And even then its quite interesting people think of it as such. D integration is not perfect, but its what most of us use. I know a lot of people in the community use it. I might as well say its the most used Code editor on earth.

VSCode is not an IDE out-of-the box, but with its extensions its able to become a much better IDE than many other actual IDEs for many use cases.

> Nevertheless, VisualD is high quality (not comparing here)...it makes sense considering the amount of work and yrs put into it.

Yes, I agree that it's amazing.

On Thursday, 9 July 2020 at 12:14:51 UTC, Jacob Carlborg wrote:
> On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote:
>
>> What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions.
>
> That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days?
>
> --
> /Jacob Carlborg

Given that Microsoft were the ones who designed LSP in the first place, I'd be surprised if the they don't. Rainer for sure knows more about it than me, but a quick Google search yields this as one of the top results:
https://docs.microsoft.com/en-us/visualstudio/extensibility/language-server-protocol?view=vs-2019

Note that this article is for VS and not VS Code.

On 08/07/2020 10:11, Walter Bright wrote:
> On 7/7/2020 6:26 PM, Manu wrote:
>> The difference is night vs day... VisualD is, by far, like REALLY FAR,
>> the most mature and useful IDE and debug environment for D.
>> TL;DR: if you are a D dev, and you use Windows, you should definitely
>> try Visual Studio + VisualD. I for one couldn't work without it!
> 
> One great thing about Rainer doing VisualD is he has leveraged that to make crucial changes to dmd's output to better work with the Visual debugger.

My first open source project was cv2pdb, a tool that converts old-style CodeView debug information generated by optlink to a PDB file. Now that this functionality is more or less available in dmd itself when compiling to COFF object files, cv2pdb seems to be more popular among C++ people using gcc on Windows, because it also allows to convert DWARF to PDB.

On 10/07/2020 07:07, Petar Kirov [ZombineDev] wrote:
> 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.

Actually the Microsoft C++ extension for VS Code also uses the Concord debug engine, but unfortunately it is not extendible as in VS (yet), see https://github.com/microsoft/vscode-cpptools/issues/2932

> 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.

I think gdb can be compared with windbg. They both have great in-depth functionality.

UX wise both are not so well, but it all depends on the front-end built on top of them. The usual downside is that remoting the text-interface can be incredibly slow.

On 09/07/2020 14:14, Jacob Carlborg wrote:
> On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote:
> 
>> What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions.
> 
> That would be really nice. Doesn't Visual Studio (not VSCode) supports
> LSP these days?
> 

There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang

It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language.

On Friday, 10 July 2020 at 05:07:38 UTC, Petar Kirov [ZombineDev] wrote:

> 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.

FYI, Visual Studio has native support for CMake projects these days.

--
/Jacob Carlborg

On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote:

> There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang
>
> It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language.

I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;)

--
/Jacob Carlborg

On 10/07/2020 09:14, Jacob Carlborg wrote:
> On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote:
> 
>> There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang
>>
>>
>> It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language.
> 
> I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;)

The semantic engine shouldn't be too hard to extract, as it is already running as a separate process. It just uses a protocol that predates LSP.

On Friday, 10 July 2020 at 00:39:49 UTC, Manu wrote:
> Even DMD itself is too  large a D project for Code-D to work well with.

I have not used Code-D, but I am using TextMate with DCD integrated. It has no problem with the DMD project. But it only supports go-to-definition, autocomplete and showing documentation for symbols.

When opening a project which contains a dub.sdl/dub.json file, the editor reads the import paths. Then it opens a new instance of DCD (one per project) and passes the imports paths to it.

> Code-D often can't even go to the definition of D functions in D code reliably ;)

Yeah, VisualD has a huge advantage since it's now using the DMD frontend for these things. For example, DCD does not support UFCS, which is really annoying.

--
/Jacob Carlborg