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:

That was before DUB became the (de-facto) official build system so he might change his mind, but right now Dutyl actually


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.

Reply via email to