On Thursday, 21 August 2014 at 08:50:50 UTC, BlackEdder wrote:
> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>
> Any idea if this plugin works in conjunction with YouCompleteMe?

YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided.
So, yes, it should work.

On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via Digitalmars-d-announce wrote:
> When I try to use this it just says that complete is not able to work at
> and suggests that DCD might not be running. Ubuntu 14.04. dcd-server and
> client are in path, even tried adding explicitly.
>
> How does one debug this plugin?
>
>
> On Thu, Aug 21, 2014 at 10:50 AM, BlackEdder via Digitalmars-d-announce <
> digitalmars-d-announce@puremagic.com> wrote:
>
>> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>
>>> I'm open for suggestions for other tools and features to add to
>>> Dutyl(write them here, or preferably open GitHub issues with them)
>>>
>>
>> Any idea if this plugin works in conjunction with YouCompleteMe?

Is the DCD server running? It needs to be running for Dutyl to use it. You can either run it manually or use the Dutyl's `:DUDCDstartServer` command.

You can check if the server is currently running by opening a shell and typing `dcd-client --query`.

Yip I tried running it manually in another terminal. Is there an error log
or something somewhere?
On 21 Aug 2014 19:00, "Idan Arye via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via Digitalmars-d-announce wrote:
>
>> When I try to use this it just says that complete is not able to work at and suggests that DCD might not be running. Ubuntu 14.04. dcd-server and client are in path, even tried adding explicitly.
>>
>> How does one debug this plugin?
>>
>>
>> On Thu, Aug 21, 2014 at 10:50 AM, BlackEdder via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>>
>>  On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>>
>>>  I'm open for suggestions for other tools and features to add to
>>>> Dutyl(write them here, or preferably open GitHub issues with them)
>>>>
>>>>
>>> Any idea if this plugin works in conjunction with YouCompleteMe?
>>>
>>
> Is the DCD server running? It needs to be running for Dutyl to use it. You can either run it manually or use the Dutyl's `:DUDCDstartServer` command.
>
> You can check if the server is currently running by opening a shell and typing `dcd-client --query`.
>

On Thursday, 21 August 2014 at 10:20:24 UTC, Weaseldog wrote:
> On Thursday, 21 August 2014 at 08:50:50 UTC, BlackEdder wrote:
>> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>>
>> Any idea if this plugin works in conjunction with YouCompleteMe?
>
> YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided.
> So, yes, it should work.

I looked a bit into YouCompleteMe to see if I can add a proper semantic completer. It appears that semantic completers run on the YCMD server rather then inside the Vim instance - which makes writing a semantic completer infeasible.

The semantic completer will need to be able to read the import paths and to invoke DCD. These two functionalities are implemented in Dutyl with VimScript - but to access these implementations it'll need to some interface to call these functions. I don't know if the YCDM-Vim interaction supports the server calling the client, or if Vim's own server-client mechanism can be used for it(which will require extra configuration), but at any rate it doesn't make much sense to use the completion server when the work is done in the Vim instance.

Another option is to reimplement that functionality in Python - but if the the import paths gathering, the DCD invokation, and the glue code that connects them are all reimplemented there is no point in making this part of Dutyl...

Also note that Dutyl sends the content of the current buffer to DCD, not the file saved on disc. This diffidently requires access to the Vim instance, and changing it is not an option unless you want to have to save before you autocomplete.

Version 1.1.0 is out now. It provides the :DUjump command for jumping to the declaration of the symbol under the cursor. If DCD is not running, Dscanner will be used instead. You can also give :DUjump the symbol as an argument - in this case it'll always use Dscanner(since DCD only supports getting the symbol by byte position).

GitHub repo: https://github.com/idanarye/vim-dutyl
vim.org page: http://www.vim.org/scripts/script.php?script_id=5003

On Wednesday, 3 September 2014 at 19:38:44 UTC, Idan Arye wrote:
> Version 1.1.0 is out now. It provides the :DUjump command for jumping to the declaration of the symbol under the cursor. If DCD is not running, Dscanner will be used instead. You can also give :DUjump the symbol as an argument - in this case it'll always use Dscanner(since DCD only supports getting the symbol by byte position).
>
> GitHub repo: https://github.com/idanarye/vim-dutyl
> vim.org page: http://www.vim.org/scripts/script.php?script_id=5003

Very nice, thanks!
This seems to be the best solution for using D with vim right now, I really need to try it out.

Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead?
This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support.
The YouCompleteMe problem would be solved too I guess.

On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:
> This way all sorts of compilers and maybe IDEs would benefit

s/compilers/editors

On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:
> Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead?
> This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support.

I already suggested it to Brian a year ago. That was his answer:
http://forum.dlang.org/thread/icfphxuqhctbqnlgliop@forum.dlang.org#post-fxtqrnpshsnrpiumkzmh:40forum.dlang.org

That was before DUB became the (de-facto) official build system so he might change his mind, but right now Dutyl actually benefits from DCD's lack of DUB support, since it means you can rely on manual configured file for non-DUB projects.

On Thursday, 4 September 2014 at 10:39:34 UTC, Idan Arye wrote:
> On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:
>> Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead?
>> This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support.
>
> I already suggested it to Brian a year ago. That was his answer:
> http://forum.dlang.org/thread/icfphxuqhctbqnlgliop@forum.dlang.org#post-fxtqrnpshsnrpiumkzmh:40forum.dlang.org
>
> That was before DUB became the (de-facto) official build system so he might change his mind, but right now Dutyl actually

https://github.com/Hackerpilot/DCD/issues/85

> benefits from DCD's lack of DUB support, since it means you can rely on manual configured file for non-DUB projects.

I don't see why the manual configured file support needs to be removed if DCD would support dub.
Wouldn't it be possible to change it to a coexisting solution?

On Thursday, 4 September 2014 at 18:11:47 UTC, Thomas Mader wrote:
> On Thursday, 4 September 2014 at 10:39:34 UTC, Idan Arye wrote:
>> On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:
>>> Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead?
>>> This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support.
>>
>> I already suggested it to Brian a year ago. That was his answer:
>> http://forum.dlang.org/thread/icfphxuqhctbqnlgliop@forum.dlang.org#post-fxtqrnpshsnrpiumkzmh:40forum.dlang.org
>>
>> That was before DUB became the (de-facto) official build system so he might change his mind, but right now Dutyl actually
>
> https://github.com/Hackerpilot/DCD/issues/85

OK, so Brian moved from not caring *for* that feature to not caring *about* the feature - probably because now we do have a de-factor standard build system. Still - it won't happen unless someone implements it and it won't be Brian because he is focusing on making DCD's(and Dscanner's... and libdparse's in general) parsing abilities even more awesome.

>> benefits from DCD's lack of DUB support, since it means you can rely on manual configured file for non-DUB projects.
>
> I don't see why the manual configured file support needs to be removed if DCD would support dub.
> Wouldn't it be possible to change it to a coexisting solution?

As long as DCD retains the ability to manually register the import paths Dutyl will keep working, but if it didn't I might have not created the config-file module and the DUB module.



At any rate, Dutyl's architecture makes sure to prevent the DCD module from knowing where it got the import paths from, to prevent the config-file and the DUB module from knowing what will be done with the import paths they provide, and to prevent the completion function from knowing which modules provided the import paths and which tools provided autoocompletion(currently only DCD can provide autocompletion, but the architecture still forces the completion function to be agnostic about that).

This means that if DCD ever gets DUB support, I'll have to either:

1) Hack the architecture and break agnosticism to make Dutyl use the dub.json for import paths in autocompletion in DUB projects. I obviously don't want to hack my own architecture in order to break the agnosticism rules I set myself...

2) Make the import gathering lazy, and add a special path for taking configuration from any project file. This will require some serious changes to the architecture so it'll take the most work, but it'll retain it's tool agnosticism.

3) Ignore DCD's DUB integration and keep providing the import paths manually.


Since parsing out the import paths from `dub describe` is blazing fast, I think I'll remain with the third option - so in the end I couldn't care less if DCD gets DUB integration.