On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:
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 kind of agree that this is not DCD's job. It seems like it is
dub's job to provide a command that prints out the import paths
in a ready-to-parse format (i.e. cleaner output than 'describe').
Well, maybe not _job_, but it would be nice.
On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:
My program can be seen here.
https://github.com/w0rp/vim/blob/master/dub_paths.d
Is there a blocker on getting something like this implemented as
`dub --print-import-paths`?
On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:
A while back, I've looked a bit into integrating Dutyl with
ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahk...@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.
Yeah, ycmd being editor agnostic means it can't rely on any vim
functionality.
Glue logic that dutyl provides will have to be implemented on the
ycmd end or the DCD end.
For example, right now I've (rather haphazardly) patched DCD to
accept a line/column number instead of a byte offset (dutyl does
this trivially with vim's line2byte).
