Support running dcd and dfmt through dub
brad-anderson opened this issue · comments
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.
Default this will definitely not be, because:
-
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...
-
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. -
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 -
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 likestd/algorithm/iteration.d
it's 30% of the totaldfmt
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', '--']
)
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.)
@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.
@idanarye This is what I get:
Oh... this is a bit... embarrassing...
I've pushed a fix to develop
. Try it.
Sorry for the delay testing. develop
works like a charm. Thanks!