Dutyl - a Vim plugin for running D tools

[Idan Arye via Digitalmars-d-announce]

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.