On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote:
> So, is there a reason not to merge the projects beyond ego?

While both share the same tools used by pretty much all editor/IDE plugins for D, dlang-vscode requires *only* those, while code-d additionally requires workspace-d.
YMMV, but that is why I used dlang-vscode exclusively.

On Wednesday, 5 July 2017 at 08:18:59 UTC, MakersF wrote:
> Having instead 3 active people on a project means that a lot of improvement and consistent work can be put into it, also easing the work needed to accept PR from the community.

Which is why it would be great to see 3+ active developers on each one ;)

On Wednesday, 5 July 2017 at 18:12:21 UTC, bitwise wrote:
> Which is why it would be great to see 3+ active developers on each one ;)

Take in account that WebFreak001 is working on serve-d...

> Microsoft language server protocol implementation for D using workspace-d.
> This program is basically a combination of workspace-d and most of code-d.
> The purpose of this project is to give every editor the same capabilities and editing  features as code-d with even less code required on the editor side than with workspace-d due to a more widely available protocol.
> This is pretty much another abstraction layer on top of workspace-d to simplify and speed up extension development as most of the editor extension can now be written in D.

His idea sound like a better future design...

On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote:
> I've been using code-d for a while, and it generally works well. I've also noticed there's another plugin available, which at the time I first looked, appeared to be older and less-featured than code-d.
>
> I've recently had a couple of colleagues ask me which plugin to install, and I noticed that both seem to be up-to-date these days, and this leads to confusion.
>
> Looking at the feature list, it appears that both plugins do mostly the
> same stuff.
> My feeling is, having 2 very similar plugins is confusing to potential
> users, and it undermines user confidence. Ie, users have the feeling that
> they're competing hacky things maintained by some guy, rather than
> something that's more 'official' with consolidated community support. I
> also tend to presume in these situations that the 'proper' one is the one
> with the most users/installs, but that's not clear either in this case.
> I know this has nothing to do with the truth, but it's about perception and
> first impressions. Little things matter.
>
> If authors of both plugins are active here, I ask; why have 2 separate
> plugins?
> I can't imagine any reason for divergence. I would be a lot more
> comfortable if there was only one with multiple contributors. Projects with
> many contributors always inspire a lot more confidence than multiple
> overlapping projects with one contributor each...
>
> So, is there a reason not to merge the projects beyond ego?

hi, code-d author here.

I personally think a merge of all of our features into one plugin would be a great idea but the problem is that the plugins work a lot differently in the code level. My plugin uses workspace-d to abstract dfmt, dcd and dscanner so the extension doesn't need to know about it and dlang-vscode simply uses the extensions directly. I am also planning on further abstracting code-d using serve-d and Microsoft's Language Server Protocol for a wider adoption and better support across editors, but that also means that the extension code will be mostly thrown out and converted to D. While this isn't such a big problem for me because most code was already in workspace-d, I think if we implemented all the features from dlang-vscode it would be a lot of work not to break things. And doing it the other way around (merging my code into dlang-vscode) would mean that all the abstraction goes away and that it would be a vscode only plugin. code-d is basically the same as the one for atom or sublime text, just with all the features implemented instead of just a subset. While I didn't really support atom or sublime text for a while, I still think it's a good idea to keep these projects around for anyone who wants to implement workspace-d or serve-d into their extension as example reference how to implement them.

But if the authors of dlang-vscode could contact me on IRC for example (WebFreak on #d on freenode) we might be able to find a solution to improve the situation and either merge into one plugin or share some code and ideas.

On Tuesday, 4 July 2017 at 06:26:52 UTC, Manu wrote:
> On 4 July 2017 at 14:59, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote:
>>
>>> If authors of both plugins are active here, I ask; why have 2 separate
>>>
>>
>> The same reason there are multiple editors.
>>
>
> Errr. No.
> I don't think you can make an argument that one plugin performs in a way
> that conforms to some peoples taste more than others... they do exactly the
> same things, and even in the same way using the same tooling.
> There might be implementation quality differences, I don't know, but that
> leads to the conclusion that merging them would produce the best quality
> result.

Personally I use dlang-vscode because it doesn't tak on an extra process used for communication. I can understand wanting to put common code into one location so that multiple editors can reuse it, but ultimately you end up writing the same code for the editors anyways. Just now instead of communicating with DCD/DScanner/etc it is doing the same thing just communicating with this new process now. It's also really buggy and you don't get any information when something goes wrong. When it does go wrong in code-d, the workspace-d crashes and you now lose access to every feature. Where as in dlang-vscode if something goes wrong with DCD you still have access to features covered by the other processes. So they are different, and I do have my preference after using both of them.

On Thursday, 6 July 2017 at 16:23:06 UTC, WebFreak001 wrote:
> While this isn't such a big problem for me because most code was already in workspace-d,

How much is actually there though? Going by lines of code, dlang-vscode is a total of ~2000 lines of code *less* than code-d. That's not including workspace-d lines of code for code-d as well. So it can provide the same features in far fewer lines and with a less complex system. Having an extra process just isn't worth it the abstraction you get cause it is so minimal. I wouldn't be trying to abstract it even further, you are just over complicating something for no reason. Keep it simple.