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.
