VSCode plugins

[WebFreak001 via Digitalmars-d]

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.