D AutoCompletion: is ycmd integration valuable?

[Idan Arye via Digitalmars-d]

On Thursday, 16 April 2015 at 01:55:09 UTC, rcorre wrote:
>> Thats great and all but not everyone is autistic enough to 
>> learn the ins and outs of Vim or Emacs...
>>
>> Visual Studio completion is very interesting as well because 
>> it can read the functions of other third party libraries 
>> automatically. Can ycmd do that?
>
> ycmd is intended to serve as a layer between a 
> completion/semantic engine (DCD/Dscanner in this case) and an 
> editor.
> Reading third party library functions would be the job of DMD 
> in this case (which it can do, if the paths are set up 
> correctly).
>
> The potential advantage of ycmd is better integration of that 
> completion info within your editor.
>
> At this point, dutyl does a good job, but there are definitely 
> areas to improve.
> Improving dutyl would involve duplicating some of ycmd's logic 
> in vimscript, while proper ycmd integration would involve 
> implementing some of dutyl's logic in python.

Some people - myself included - have already asked Brian to make 
DCD read the project's import paths from Dub or something. At 
first he claimed this is the editor's job - now he seems to be 
accepting the idea enough to accept a pull request - but he 
doesn't care about it enough to implement it himself.

I won't be doing it either, because Dutyl is already doing this 
job and feeding the import paths to DCD, I'm assuming the other 
editor plugins also have their solutions for that already, so you 
can count their maintainers out. You'll need someone new to have 
enough motivation to do it - someone who wants to develop a new 
editor plugin(or plugin for ymcd or 
https://github.com/quarnster/completion or other stuff like that) 
and is willing to contribute to DCD on the way.

A while back, I've looked a bit into integrating Dutyl with 
ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd@forum.dlang.org?page=2#post-ahwguxayeamrvdczlacu:40forum.dlang.org) 
and found out this connection is a waste of time, since I'll have 
to reimplement all the relevant parts in Python anyways so there 
is no point to make the semantic engine depend on Dutyl.