On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote:
> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>> GitHub repo: https://github.com/idanarye/vim-dutyl
>> vim.org page: http://www.vim.org/scripts/script.php?script_id=5003
>>
>> The main problem with my Vim plugin for DCD(placed inside the DCD repo) is the need to set the import paths manually. It was a manual task that the user had to do: DCD doesn't know the import path the current project is using. Vim doesn't know either.
>>
>> Luckily - DUB knows. So instead of separate Vim plugins for different tools, each operating it's own tool alone, I wanted to create one plugin that'll operate both DUB and DCD - one that can get the list of import modules from DUB and send it to DCD. That's how Dutyl was born.
>>
>> Currently, Dutyl's only features are using DCD for autocompletion and for DDocs, but it has a module system that allows it to add other tools, either to get more functionality or to get backup for features that some tools can't support for specific projects. Like dependency injection but with a real usecase: for projects that don't use DUB, Dutyl can back up to a manually written list of import paths saved in a hidden file in the project's dir.
>>
>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>
> How does dutyl know where to look for dub.json? It doesn't seem to find it on my system.

It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".

On Sunday, 28 September 2014 at 11:51:21 UTC, Idan Arye wrote:
> On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote:
>> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>> GitHub repo: https://github.com/idanarye/vim-dutyl
>>> vim.org page: http://www.vim.org/scripts/script.php?script_id=5003
>>>
>>> The main problem with my Vim plugin for DCD(placed inside the DCD repo) is the need to set the import paths manually. It was a manual task that the user had to do: DCD doesn't know the import path the current project is using. Vim doesn't know either.
>>>
>>> Luckily - DUB knows. So instead of separate Vim plugins for different tools, each operating it's own tool alone, I wanted to create one plugin that'll operate both DUB and DCD - one that can get the list of import modules from DUB and send it to DCD. That's how Dutyl was born.
>>>
>>> Currently, Dutyl's only features are using DCD for autocompletion and for DDocs, but it has a module system that allows it to add other tools, either to get more functionality or to get backup for features that some tools can't support for specific projects. Like dependency injection but with a real usecase: for projects that don't use DUB, Dutyl can back up to a manually written list of import paths saved in a hidden file in the project's dir.
>>>
>>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>>
>> How does dutyl know where to look for dub.json? It doesn't seem to find it on my system.
>
> It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".

Ah, ok. Is it feasible to have it check up the directory tree as well, like git does? I often find myself in this situation:

myProject
|- dub.json
|- source  <- vim pwd here
   |- app.d

and so Dutyl misses myProject/dub.json

On Monday, 29 September 2014 at 16:09:04 UTC, John Colvin wrote:
> On Sunday, 28 September 2014 at 11:51:21 UTC, Idan Arye wrote:
>> On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote:
>>> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>>> GitHub repo: https://github.com/idanarye/vim-dutyl
>>>> vim.org page: http://www.vim.org/scripts/script.php?script_id=5003
>>>>
>>>> The main problem with my Vim plugin for DCD(placed inside the DCD repo) is the need to set the import paths manually. It was a manual task that the user had to do: DCD doesn't know the import path the current project is using. Vim doesn't know either.
>>>>
>>>> Luckily - DUB knows. So instead of separate Vim plugins for different tools, each operating it's own tool alone, I wanted to create one plugin that'll operate both DUB and DCD - one that can get the list of import modules from DUB and send it to DCD. That's how Dutyl was born.
>>>>
>>>> Currently, Dutyl's only features are using DCD for autocompletion and for DDocs, but it has a module system that allows it to add other tools, either to get more functionality or to get backup for features that some tools can't support for specific projects. Like dependency injection but with a real usecase: for projects that don't use DUB, Dutyl can back up to a manually written list of import paths saved in a hidden file in the project's dir.
>>>>
>>>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>>>
>>> How does dutyl know where to look for dub.json? It doesn't seem to find it on my system.
>>
>> It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".
>
> Ah, ok. Is it feasible to have it check up the directory tree as well, like git does? I often find myself in this situation:
>
> myProject
> |- dub.json
> |- source  <- vim pwd here
>    |- app.d
>
> and so Dutyl misses myProject/dub.json

Seems a little weird to do so, considering that DUB itself does not look up in the directory tree...

On Tuesday, 30 September 2014 at 08:27:27 UTC, Idan Arye wrote:
> On Monday, 29 September 2014 at 16:09:04 UTC, John Colvin wrote:
>> On Sunday, 28 September 2014 at 11:51:21 UTC, Idan Arye wrote:
>>> On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote:
>>>> On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
>>>>> GitHub repo: https://github.com/idanarye/vim-dutyl
>>>>> vim.org page: http://www.vim.org/scripts/script.php?script_id=5003
>>>>>
>>>>> The main problem with my Vim plugin for DCD(placed inside the DCD repo) is the need to set the import paths manually. It was a manual task that the user had to do: DCD doesn't know the import path the current project is using. Vim doesn't know either.
>>>>>
>>>>> Luckily - DUB knows. So instead of separate Vim plugins for different tools, each operating it's own tool alone, I wanted to create one plugin that'll operate both DUB and DCD - one that can get the list of import modules from DUB and send it to DCD. That's how Dutyl was born.
>>>>>
>>>>> Currently, Dutyl's only features are using DCD for autocompletion and for DDocs, but it has a module system that allows it to add other tools, either to get more functionality or to get backup for features that some tools can't support for specific projects. Like dependency injection but with a real usecase: for projects that don't use DUB, Dutyl can back up to a manually written list of import paths saved in a hidden file in the project's dir.
>>>>>
>>>>> I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them)
>>>>
>>>> How does dutyl know where to look for dub.json? It doesn't seem to find it on my system.
>>>
>>> It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".
>>
>> Ah, ok. Is it feasible to have it check up the directory tree as well, like git does? I often find myself in this situation:
>>
>> myProject
>> |- dub.json
>> |- source  <- vim pwd here
>>   |- app.d
>>
>> and so Dutyl misses myProject/dub.json
>
> Seems a little weird to do so, considering that DUB itself does not look up in the directory tree...

True, but it does make auto-complete work properly when you open a single source file in a project, without having to manually set the current directory. Vim's current directory (either global or per-window) isn't part of my workflow*.

It could be an optional feature (a flag in .vimrc would be fine) with an override (temporarily manually specify the location of dub.json), but I think it makes a significant usability improvement.


I'm trying to think of a pathological case where it would be a bad idea, but I can't think of anything realistic.


*Am I doing something very wrong here? If using (l)cd in vim is part of almost everyone's workflow I should probably just start using it more and stop complaining :)

On Tuesday, 30 September 2014 at 08:47:43 UTC, John Colvin wrote:
> True, but it does make auto-complete work properly when you open a single source file in a project, without having to manually set the current directory. Vim's current directory (either global or per-window) isn't part of my workflow*.
>
> It could be an optional feature (a flag in .vimrc would be fine) with an override (temporarily manually specify the location of dub.json), but I think it makes a significant usability improvement.
>
>
> I'm trying to think of a pathological case where it would be a bad idea, but I can't think of anything realistic.
>
>
> *Am I doing something very wrong here? If using (l)cd in vim is part of almost everyone's workflow I should probably just start using it more and stop complaining :)

I usually open Vim at the project's and use NERDTree to navigate the file, but I suppose people that start Vim directly on the file they want to edit won't bother `cd`ing to the project's root every time, so we shouldn't force them to do so just so they can use Dutyl...

If I'm going to look up the tree to find dub.json anyways, I might as well export the project's root as part of the API. I can add a `dutyl#projectRoot()` that returns that value, and I can also add `:DUexecute` command that'll run a command in the project's root. That'll make it easier to call DUB from Vim using your type of workflow.

I'm still pondering though what to with the ConfigFile feature. `.dutyl.configFile` should mark the project's root, but it's creation could prove problematic. If the user opens a file deep in the source tree and runs `:DUConfigFileEditImportPaths` from there it'll create the config file in the wrong place...

On Tuesday, 30 September 2014 at 15:52:46 UTC, Idan Arye wrote:
> On Tuesday, 30 September 2014 at 08:47:43 UTC, John Colvin wrote:
>> True, but it does make auto-complete work properly when you open a single source file in a project, without having to manually set the current directory. Vim's current directory (either global or per-window) isn't part of my workflow*.
>>
>> It could be an optional feature (a flag in .vimrc would be fine) with an override (temporarily manually specify the location of dub.json), but I think it makes a significant usability improvement.
>>
>>
>> I'm trying to think of a pathological case where it would be a bad idea, but I can't think of anything realistic.
>>
>>
>> *Am I doing something very wrong here? If using (l)cd in vim is part of almost everyone's workflow I should probably just start using it more and stop complaining :)
>
> I usually open Vim at the project's and use NERDTree to navigate the file, but I suppose people that start Vim directly on the file they want to edit won't bother `cd`ing to the project's root every time, so we shouldn't force them to do so just so they can use Dutyl...
>
> If I'm going to look up the tree to find dub.json anyways, I might as well export the project's root as part of the API. I can add a `dutyl#projectRoot()` that returns that value, and I can also add `:DUexecute` command that'll run a command in the project's root. That'll make it easier to call DUB from Vim using your type of workflow.
>
> I'm still pondering though what to with the ConfigFile feature. `.dutyl.configFile` should mark the project's root, but it's creation could prove problematic. If the user opens a file deep in the source tree and runs `:DUConfigFileEditImportPaths` from there it'll create the config file in the wrong place...

And... it's done. Check out version 1.4.0

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