Dutyl - a Vim plugin for running D tools
Idan Arye via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Tue Sep 30 08:52:45 PDT 2014
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...
More information about the Digitalmars-d-announce
mailing list