www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Dutyl - a Vim plugin for running D tools

reply "Idan Arye" <GenericNPC gmail.com> writes:
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)
Aug 14 2014
next sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
nice, thanks
Aug 15 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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)


Nice, I was planning on doing something just like this someday.
Aug 15 2014
prev sibling next sibling parent reply "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
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


Very very nice... So... how does it work?

I added a Bundle "idanarye/vim-dutyl" to my $MTVIMRC.
I added the following three lines as well

let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')

When I try to do a completion with ctrl-X ctrl-O I get DCD server 
to only output some errors:
Cannot cache modules in 
C:\some\folder\for\dub\packages\derelict-blabla\" -I 
E:\my\project\subfolder" because it does not exist

(The folders are in the filesystem, I can confirm they DO exist)
Am I missing something, or should I open an issue at github?
Aug 18 2014
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio 
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


 Very very nice... So... how does it work?

 I added a Bundle "idanarye/vim-dutyl" to my $MTVIMRC.
 I added the following three lines as well

 let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
 call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
 call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')

 When I try to do a completion with ctrl-X ctrl-O I get DCD 
 server to only output some errors:
 Cannot cache modules in 
 C:\some\folder\for\dub\packages\derelict-blabla\" -I 
 E:\my\project\subfolder" because it does not exist

 (The folders are in the filesystem, I can confirm they DO exist)
 Am I missing something, or should I open an issue at github?


This is not the only Dutyl Windows problem - I'm currently fixing 
them in the `feature/fix-windows-issues` branch. Currently I 
solved unix-vs-windows file format problem and a problem with 
VimProc different shell escape conventions, but it doesn't seem 
like this is the problem here - looks more like a path format 
problem.

At any rate, please open a GitHub issue, and it would help if you 
can run the vim command

     let 
 +=string(dutyl#core#requireFunctions('importPaths').importPaths())

in your project's folder. It will it'll place something in your 
clipboard - please paste it in the GitHub issue.
Aug 18 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 18 August 2014 at 12:36:42 UTC, Idan Arye wrote:

 On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio 
 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


 Very very nice... So... how does it work?

 I added a Bundle "idanarye/vim-dutyl" to my $MTVIMRC.
 I added the following three lines as well

 let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
 call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
 call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')

 When I try to do a completion with ctrl-X ctrl-O I get DCD 
 server to only output some errors:
 Cannot cache modules in 
 C:\some\folder\for\dub\packages\derelict-blabla\" -I 
 E:\my\project\subfolder" because it does not exist

 (The folders are in the filesystem, I can confirm they DO 
 exist)
 Am I missing something, or should I open an issue at github?


 This is not the only Dutyl Windows problem - I'm currently 
 fixing them in the `feature/fix-windows-issues` branch. 
 Currently I solved unix-vs-windows file format problem and a 
 problem with VimProc different shell escape conventions, but it 
 doesn't seem like this is the problem here - looks more like a 
 path format problem.

 At any rate, please open a GitHub issue, and it would help if 
 you can run the vim command

     let 
  +=string(dutyl#core#requireFunctions('importPaths').importPaths())

 in your project's folder. It will it'll place something in your 
 clipboard - please paste it in the GitHub issue.


My bad - turns out it was related to shell escape conventions, 
though this particular problem was introduced in the 
`feature/fix-windows-issues` branch. Was this the one you were 
using?

At any rate, it's fixed now in that branch, and I aim to merge it 
tomorrow and release a bugfix version.
Aug 18 2014
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio 
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


 Very very nice... So... how does it work?

 I added a Bundle "idanarye/vim-dutyl" to my $MTVIMRC.
 I added the following three lines as well

 let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
 call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
 call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')

 When I try to do a completion with ctrl-X ctrl-O I get DCD 
 server to only output some errors:
 Cannot cache modules in 
 C:\some\folder\for\dub\packages\derelict-blabla\" -I 
 E:\my\project\subfolder" because it does not exist

 (The folders are in the filesystem, I can confirm they DO exist)
 Am I missing something, or should I open an issue at github?


OK, I found the real culprit - it's the backslash before the 
double quotes. Even tough Windows uses backqoutes for separation, 
it still uses them as escape characters when placed before 
special characters...

Anyways, version 1.0.1 is out with many bugfixes and speedups - 
including a fix for this problem.
Aug 19 2014
parent "francesco cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 19 August 2014 at 19:03:45 UTC, Idan Arye wrote:

 Anyways, version 1.0.1 is out with many bugfixes and speedups - 
 including a fix for this problem.


I can confirm it works under windows now! Very good job, and 
thank you for your efforts :)
Aug 20 2014
prev sibling next sibling parent reply "BlackEdder" <edder tkwsping.nl> writes:
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?
Aug 21 2014
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
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?
Aug 21 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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`.
Aug 21 2014
parent Rory McGuire via Digitalmars-d-announce writes:
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`.
Aug 21 2014
prev sibling parent reply "Weaseldog" <weaseldog gmail.com> writes:
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.
Aug 21 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
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.
Aug 21 2014
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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
Sep 03 2014
next sibling parent reply "Thomas Mader" <thomas.mader gmail.com> writes:
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.
Sep 03 2014
next sibling parent "Thomas Mader" <thomas.mader gmail.com> writes:
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
Sep 03 2014
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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.
Sep 04 2014
parent reply "Thomas Mader" <thomas.mader gmail.com> writes:
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?
Sep 04 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
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.
Sep 04 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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


Can DUjump be set to open in a new window (internal to vim, not a 
new instance of vim)? For an example of why this would be better: 
you can't currently use DUjump if the file has unsaved changes.
Sep 07 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 7 September 2014 at 18:14:33 UTC, John Colvin wrote:

 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


 Can DUjump be set to open in a new window (internal to vim, not 
 a new instance of vim)? For an example of why this would be 
 better: you can't currently use DUjump if the file has unsaved 
 changes.


Sure, no problem, I'll get to it in the next release.

To be consistent with other Vim commands I'm gonna add :DUsjump 
and DUvjump for jumping in new windows.

I also plan on adding the bang option - :DUjump!(and it's split 
variants) - which will force it to use Dscanner even if DCD is 
running. I find that sometimes it's becoming too complicated for 
DCD to follow the declarations chain all the way to the source, 
and Dscanner - which gets the symbol from the command line 
arguments instead of a getting a byte position in a file - 
performs better. Even if it can't filter to find the exact 
declaration that I'm looking for, it displays multiple options 
that the one I'm looking for is among them, which is better than 
DCD that can't follow the entire chain and finds nothing.
Sep 07 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 7 September 2014 at 20:07:20 UTC, Idan Arye wrote:

 On Sunday, 7 September 2014 at 18:14:33 UTC, John Colvin wrote:

 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


 Can DUjump be set to open in a new window (internal to vim, 
 not a new instance of vim)? For an example of why this would 
 be better: you can't currently use DUjump if the file has 
 unsaved changes.


 Sure, no problem, I'll get to it in the next release.

 To be consistent with other Vim commands I'm gonna add :DUsjump 
 and DUvjump for jumping in new windows.

 I also plan on adding the bang option - :DUjump!(and it's split 
 variants) - which will force it to use Dscanner even if DCD is 
 running. I find that sometimes it's becoming too complicated 
 for DCD to follow the declarations chain all the way to the 
 source, and Dscanner - which gets the symbol from the command 
 line arguments instead of a getting a byte position in a file - 
 performs better. Even if it can't filter to find the exact 
 declaration that I'm looking for, it displays multiple options 
 that the one I'm looking for is among them, which is better 
 than DCD that can't follow the entire chain and finds nothing.


Annnnnnnd... it's done. :DUsjump and :DUvjump will split the 
window before they jump. Also added the bang version.

I'm not making a new release yet(I still want to add another 
feature before that), but it's in the develop branch in GitHub.
Sep 08 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
Version 1.2.0 is out now. I've added the command :DUsyntaxCheck, 
:DUlsyntaxCheck :DUstyleCheck, and :DUlstyleCheck to run 
Dscanner's syntax or style checks and store the results in the 
quickfix or location list. As per Vim's conventions for commands 
that update these lists, it'll automatically jump to the first 
entry unless the command is called with a bang.

GitHub repo: https://github.com/idanarye/vim-dutyl
vim.org page: http://www.vim.org/scripts/script.php?script_id=5003
Sep 13 2014
parent reply "Andrei Amatuni" <andrei.amatuni gmail.com> writes:
On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye wrote:

 Version 1.2.0 is out now. I've added the command 
 :DUsyntaxCheck, :DUlsyntaxCheck :DUstyleCheck, and 
 :DUlstyleCheck to run Dscanner's syntax or style checks and 
 store the results in the quickfix or location list. As per 
 Vim's conventions for commands that update these lists, it'll 
 automatically jump to the first entry unless the command is 
 called with a bang.

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


I just updated both Dutyl and DCD and something broke along the 
way. I can see that Vim is communicating with DCD because the DCD 
server log shows that it received a request after a dot 
completion, but nothing shows up in Vim.
Sep 13 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni
wrote:

 On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye wrote:

 Version 1.2.0 is out now. I've added the command 
 :DUsyntaxCheck, :DUlsyntaxCheck :DUstyleCheck, and 
 :DUlstyleCheck to run Dscanner's syntax or style checks and 
 store the results in the quickfix or location list. As per 
 Vim's conventions for commands that update these lists, it'll 
 automatically jump to the first entry unless the command is 
 called with a bang.

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


 I just updated both Dutyl and DCD and something broke along the 
 way. I can see that Vim is communicating with DCD because the 
 DCD server log shows that it received a request after a dot 
 completion, but nothing shows up in Vim.


The problem was with Dutyl - I used the `uniq` function, which
apparently was bleeding
new(https://github.com/LaTeX-Box-Team/LaTeX-Box/issues/190#issuecomment-47459338).

The fix is in `develop` now. It worked for me(on my Windows
installation - which has a not-as-up-to-date version of Vim as my
Linux installation) - let me know it works for you and I'll make
it an official bugfix.
Sep 14 2014
parent reply "Andrei Amatuni" <andrei.amatuni gmail.com> writes:
On Sunday, 14 September 2014 at 20:06:13 UTC, Idan Arye wrote:

 On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni
 wrote:

 On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye 
 wrote:

 Version 1.2.0 is out now. I've added the command 
 :DUsyntaxCheck, :DUlsyntaxCheck :DUstyleCheck, and 
 :DUlstyleCheck to run Dscanner's syntax or style checks and 
 store the results in the quickfix or location list. As per 
 Vim's conventions for commands that update these lists, it'll 
 automatically jump to the first entry unless the command is 
 called with a bang.

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


 I just updated both Dutyl and DCD and something broke along 
 the way. I can see that Vim is communicating with DCD because 
 the DCD server log shows that it received a request after a 
 dot completion, but nothing shows up in Vim.


 The problem was with Dutyl - I used the `uniq` function, which
 apparently was bleeding
 new(https://github.com/LaTeX-Box-Team/LaTeX-Box/issues/190#issuecomment-47459338).

 The fix is in `develop` now. It worked for me(on my Windows
 installation - which has a not-as-up-to-date version of Vim as 
 my
 Linux installation) - let me know it works for you and I'll make
 it an official bugfix.



Just updated it. It's working about 60-70% of the time now.
Sometimes it won't complete at first, and then after erasing and
retyping once or twice it'll show the completions. Thanks for the
quick fix though!
Sep 14 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 14 September 2014 at 20:42:54 UTC, Andrei Amatuni
wrote:

 On Sunday, 14 September 2014 at 20:06:13 UTC, Idan Arye wrote:

 On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni
 wrote:

 On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye 
 wrote:

 Version 1.2.0 is out now. I've added the command 
 :DUsyntaxCheck, :DUlsyntaxCheck :DUstyleCheck, and 
 :DUlstyleCheck to run Dscanner's syntax or style checks and 
 store the results in the quickfix or location list. As per 
 Vim's conventions for commands that update these lists, 
 it'll automatically jump to the first entry unless the 
 command is called with a bang.

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


 I just updated both Dutyl and DCD and something broke along 
 the way. I can see that Vim is communicating with DCD because 
 the DCD server log shows that it received a request after a 
 dot completion, but nothing shows up in Vim.


 The problem was with Dutyl - I used the `uniq` function, which
 apparently was bleeding
 new(https://github.com/LaTeX-Box-Team/LaTeX-Box/issues/190#issuecomment-47459338).

 The fix is in `develop` now. It worked for me(on my Windows
 installation - which has a not-as-up-to-date version of Vim as 
 my
 Linux installation) - let me know it works for you and I'll 
 make
 it an official bugfix.



 Just updated it. It's working about 60-70% of the time now.
 Sometimes it won't complete at first, and then after erasing and
 retyping once or twice it'll show the completions. Thanks for 
 the
 quick fix though!


I've noticed these things too. Might be an off-by-one mistake
with the byte position calculation. That'll have to wait for the
next bugfix version though - I've just released the bugfix for
the `uniq` problem(v1.2.1).
Sep 14 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
OK, version 1.3.0 is out. I fixed that off-by-one mistake and 
added some tags-related features:

  * A new command - :DUupdateCTags - for updating the tags file
  * DUjump and friends now push to the tag stack, so you can jump 
back with CTRL+T.
Sep 15 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Sep 25 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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".
Sep 28 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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
Sep 29 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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...
Sep 30 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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 :)
Sep 30 2014
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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...
Sep 30 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
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
Oct 04 2014