Support running dcd and dfmt through dub

[brad-anderson]

DUB makes it trivial to install dcd and dfmt. It also solves the problem of having to identify paths because you can just execute them like so:

dub run --config=client --build=release dcd
dub run --config=server --build=release dcd

Specifying the dub run command in dutyl#register#tool doesn't work however (it errors with 'dub run --config=client --build=release dcd' is not an executable).

I think the ideal configuration would be to just default to running them through dub (if dub is available). This means all users of every platform would only have to install dub and run dub fetch for dcd and dfmt and they'd be ready to go with vim-dutyl.

[idanarye]

Default this will definitely not be, because:

1. One of Dutyl's promises is to only require the actual tools you want to use. It's reasonable to not support extracting import paths from Dub projects if Dub is not installed. It's less reasonable to not support code formatting if Dub is not installed...
2. This requires users to dub fetch, and I don't have a sane way to convey this to upgrading users: I refuse to rely on users reading the release notes, and if I make this an error message I break my promise to not require tools the user doesn't actually use.
3. If they just do dub fetch(or neglect to build with the correct --build flag), Vim will freeze for seconds to minutes the first time they use the tool. The users will get no indication for that, because the tools are called behind the scene. A very unpleasant suprise, even if it only happens

4. Dub overhead - not that much but still significant, but when I use dfmt to indent I call it many times so it adds up. On a big like std/algorithm/iteration.d it's 30% of the total dfmt time - on smaller files it'll be more significant.

   $ wc -l iteration.d 
   4286 iteration.d
   $ time dfmt < iteration.d > /dev/null
   
   real    0m0.103s
   user    0m0.100s
   sys     0m0.000s
   $ time dfmt < iteration.d > /dev/null
   
   real    0m0.101s
   user    0m0.100s
   sys     0m0.000s
   $ time dfmt < iteration.d > /dev/null
   
   real    0m0.100s
   user    0m0.093s
   sys     0m0.007s
   $ time dfmt < iteration.d > /dev/null
   
   real    0m0.100s
   user    0m0.093s
   sys     0m0.003s
   $ time dub --quiet --build=release dfmt -- < iteration.d > /dev/null
   
   real    0m0.129s
   user    0m0.123s
   sys     0m0.003s
   $ time dub --quiet --build=release dfmt -- < iteration.d > /dev/null
   
   real    0m0.133s
   user    0m0.130s
   sys     0m0.000s
   $ time dub --quiet --build=release dfmt -- < iteration.d > /dev/null
   
   real    0m0.131s
   user    0m0.123s
   sys     0m0.003s
   $ time dub --quiet --build=release dfmt -- < iteration.d > /dev/null
   
   real    0m0.130s
   user    0m0.120s
   sys     0m0.007s

That being said - if the user chooses to use Dub for this, I should allow it. You'll have to use an array of arguments though(['dub', 'run', '--config=client', '--build=release', 'dcd', '--'])

[brad-anderson]

All good reasons. You've clearly thought this through more than I have. We can close this.

(While I have your attention, when I use gq the lines I am affecting just disappear from my file. What's the best way to diagnose what is causing this so I can file an issue? dfmt tool path is specified correctly and dfmt runs fine on the file from the command line.)

[idanarye]

@eco what happens when you run this:

let dutyl = dutyl#core#requireFunctions('formatCode')

echo join(dutyl.formatCode([
      \ 'import std.stdio;',
      \ '',
      \ 'void main(){',
      \ 'writeln("hello");',
      \ '}'
      \ ]), "\n")

(just put it in a .vim file and :source it.

[brad-anderson]

@idanarye This is what I get:

[idanarye]

Oh... this is a bit... embarrassing...

I've pushed a fix to develop. Try it.

[brad-anderson]

Sorry for the delay testing. develop works like a charm. Thanks!