Dutyl - a Vim plugin for running D tools

nice, thanks

Brad Anderson via Digitalmars-d-announce

2014-08-15 19:44:14 UTC

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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.

francesco cattoglio via Digitalmars-d-announce

2014-08-18 07:24:27 UTC

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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?

Idan Arye via Digitalmars-d-announce

2014-08-18 12:36:40 UTC

Post by francesco cattoglio via Digitalmars-d-announce

On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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
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.

Idan Arye via Digitalmars-d-announce

2014-08-18 20:42:28 UTC

Post by francesco cattoglio via Digitalmars-d-announce

Post by Idan Arye via Digitalmars-d-announce
On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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
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.

Idan Arye via Digitalmars-d-announce

2014-08-19 19:03:43 UTC

Post by francesco cattoglio via Digitalmars-d-announce

On Monday, 18 August 2014 at 07:24:28 UTC, francesco cattoglio

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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
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.

francesco cattoglio via Digitalmars-d-announce

2014-08-20 08:47:21 UTC

Post by Idan Arye via Digitalmars-d-announce
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 :)

BlackEdder via Digitalmars-d-announce

2014-08-21 08:50:49 UTC

Post by Idan Arye via Digitalmars-d-announce
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?

Rory McGuire via Digitalmars-d-announce

2014-08-21 08:57:39 UTC

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 <

Post by Idan Arye via Digitalmars-d-announce
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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140821/4b4440f6/attachment.html>

Weaseldog via Digitalmars-d-announce

2014-08-21 10:20:22 UTC

Post by Idan Arye via Digitalmars-d-announce
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.

Idan Arye via Digitalmars-d-announce

2014-08-21 17:57:22 UTC

Post by Weaseldog via Digitalmars-d-announce

Post by Idan Arye via Digitalmars-d-announce
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.

Idan Arye via Digitalmars-d-announce

2014-08-21 16:59:20 UTC

On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via

Post by Rory McGuire via Digitalmars-d-announce
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 <

Post by Idan Arye via Digitalmars-d-announce
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`.

Rory McGuire via Digitalmars-d-announce

2014-08-21 17:52:13 UTC

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" <

Post by Idan Arye via Digitalmars-d-announce
On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via

Post by Rory McGuire via Digitalmars-d-announce
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 <

Post by Idan Arye via Digitalmars-d-announce
I'm open for suggestions for other tools and features to add to

Post by Idan Arye via Digitalmars-d-announce
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`.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140821/dc7bbd72/attachment.html>

Idan Arye via Digitalmars-d-announce

2014-09-03 19:38:42 UTC

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

Thomas Mader via Digitalmars-d-announce

2014-09-04 05:58:17 UTC

Post by Idan Arye via Digitalmars-d-announce
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
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.

Thomas Mader via Digitalmars-d-announce

2014-09-04 05:59:42 UTC

Post by Thomas Mader via Digitalmars-d-announce
This way all sorts of compilers and maybe IDEs would benefit

s/compilers/editors

Idan Arye via Digitalmars-d-announce

2014-09-04 10:39:33 UTC

Post by Thomas Mader via Digitalmars-d-announce
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 at 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.

Thomas Mader via Digitalmars-d-announce

2014-09-04 18:11:45 UTC

On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader

http://forum.dlang.org/thread/icfphxuqhctbqnlgliop at 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?

Idan Arye via Digitalmars-d-announce

2014-09-05 02:40:30 UTC

Post by Thomas Mader via Digitalmars-d-announce

On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader

Post by Thomas Mader via Digitalmars-d-announce
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
http://forum.dlang.org/thread/icfphxuqhctbqnlgliop at 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.

Post by Thomas Mader via Digitalmars-d-announce

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.

John Colvin via Digitalmars-d-announce

2014-09-07 18:14:31 UTC

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.

Idan Arye via Digitalmars-d-announce

2014-09-07 20:07:18 UTC

Post by Idan Arye via Digitalmars-d-announce
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
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.

Idan Arye via Digitalmars-d-announce

2014-09-08 19:20:14 UTC

Post by Idan Arye via Digitalmars-d-announce

On Wednesday, 3 September 2014 at 19:38:44 UTC, Idan Arye

Post by Idan Arye via Digitalmars-d-announce
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
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.

Idan Arye via Digitalmars-d-announce

2014-09-13 15:19:54 UTC

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

Andrei Amatuni via Digitalmars-d-announce

2014-09-14 03:22:34 UTC

Post by Idan Arye via Digitalmars-d-announce
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
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.

Idan Arye via Digitalmars-d-announce

2014-09-14 20:06:12 UTC

Post by Andrei Amatuni via Digitalmars-d-announce

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

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.

Andrei Amatuni via Digitalmars-d-announce

2014-09-14 20:42:53 UTC

Post by Idan Arye via Digitalmars-d-announce
On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni

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

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!

Idan Arye via Digitalmars-d-announce

2014-09-14 21:30:24 UTC

Post by Andrei Amatuni via Digitalmars-d-announce

On Sunday, 14 September 2014 at 20:42:54 UTC, Andrei Amatuni

Post by Idan Arye via Digitalmars-d-announce
On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni

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

Post by Idan Arye via Digitalmars-d-announce
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
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.

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).

Idan Arye via Digitalmars-d-announce

2014-09-15 20:40:20 UTC

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.

John Colvin via Digitalmars-d-announce

2014-09-25 15:40:21 UTC

How does dutyl know where to look for dub.json? It doesn't seem
to find it on my system.

Idan Arye via Digitalmars-d-announce

2014-09-28 11:51:19 UTC

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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".

John Colvin via Digitalmars-d-announce

2014-09-29 16:09:03 UTC

On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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

Idan Arye via Digitalmars-d-announce

2014-09-30 08:27:24 UTC

On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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
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...

John Colvin via Digitalmars-d-announce

2014-09-30 08:47:41 UTC

Post by Idan Arye via Digitalmars-d-announce

On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin

Post by Idan Arye via Digitalmars-d-announce
GitHub repo: https://github.com/idanarye/vim-dutyl
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
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 :)

Idan Arye via Digitalmars-d-announce

2014-09-30 15:52:45 UTC

Post by John Colvin via Digitalmars-d-announce
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...

Idan Arye via Digitalmars-d-announce

2014-10-04 18:23:01 UTC