digitalmars.D.announce - Dutyl - a Vim plugin for running D tools
- Idan Arye (20/20) Aug 14 2014 GitHub repo: https://github.com/idanarye/vim-dutyl
- Robert burner Schadek (1/1) Aug 15 2014 nice, thanks
- Brad Anderson (2/26) Aug 15 2014 Nice, I was planning on doing something just like this someday.
- francesco cattoglio (14/17) Aug 18 2014 Very very nice... So... how does it work?
- Idan Arye (14/31) Aug 18 2014 This is not the only Dutyl Windows problem - I'm currently fixing
- Idan Arye (7/44) Aug 18 2014 My bad - turns out it was related to shell escape conventions,
- Idan Arye (8/25) Aug 19 2014 OK, I found the real culprit - it's the backslash before the
- francesco cattoglio (3/5) Aug 20 2014 I can confirm it works under windows now! Very good job, and
- BlackEdder (2/5) Aug 21 2014 Any idea if this plugin works in conjunction with YouCompleteMe?
- Rory McGuire via Digitalmars-d-announce (6/11) Aug 21 2014 When I try to use this it just says that complete is not able to work at
- Idan Arye (7/26) Aug 21 2014 Is the DCD server running? It needs to be running for Dutyl to
- Rory McGuire via Digitalmars-d-announce (4/29) Aug 21 2014 Yip I tried running it manually in another terminal. Is there an error l...
- Weaseldog (4/9) Aug 21 2014 YouCompleteMe will use the available omnifunc as a fallback if no
- Idan Arye (22/33) Aug 21 2014 I looked a bit into YouCompleteMe to see if I can add a proper
- Idan Arye (8/8) Sep 03 2014 Version 1.1.0 is out now. It provides the :DUjump command for
- Thomas Mader (10/19) Sep 03 2014 Very nice, thanks!
- Thomas Mader (2/3) Sep 03 2014 s/compilers/editors
- Idan Arye (7/12) Sep 04 2014 I already suggested it to Brian a year ago. That was his answer:
- Thomas Mader (5/18) Sep 04 2014 I don't see why the manual configured file support needs to be
- Idan Arye (32/54) Sep 04 2014 OK, so Brian moved from not caring *for* that feature to not
- John Colvin (4/13) Sep 07 2014 Can DUjump be set to open in a new window (internal to vim, not a
- Idan Arye (14/29) Sep 07 2014 Sure, no problem, I'll get to it in the next release.
- Idan Arye (5/36) Sep 08 2014 Annnnnnnd... it's done. :DUsjump and :DUvjump will split the
- Idan Arye (8/8) Sep 13 2014 Version 1.2.0 is out now. I've added the command :DUsyntaxCheck,
- Andrei Amatuni (5/15) Sep 13 2014 I just updated both Dutyl and DCD and something broke along the
- Idan Arye (9/25) Sep 14 2014 The problem was with Dutyl - I used the `uniq` function, which
- Andrei Amatuni (5/33) Sep 14 2014 Just updated it. It's working about 60-70% of the time now.
- John Colvin (3/27) Sep 25 2014 How does dutyl know where to look for dub.json? It doesn't seem
- Idan Arye (3/34) Sep 28 2014 It looks for a file named "dub.json" in the current folder. If it
- John Colvin (8/44) Sep 29 2014 Ah, ok. Is it feasible to have it check up the directory tree as
- Idan Arye (3/48) Sep 30 2014 Seems a little weird to do so, considering that DUB itself does
- John Colvin (14/65) Sep 30 2014 True, but it does make auto-complete work properly when you open
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
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
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=5003Very 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
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: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.GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003Very 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
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: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.On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: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.GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003Very 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
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: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.GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003Very 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 19 2014
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
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
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
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: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`.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
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: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`.I'm open for suggestions for other tools and features to add toDutyl(write them here, or preferably open GitHub issues with them)Any idea if this plugin works in conjunction with YouCompleteMe?
Aug 21 2014
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:YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided. So, yes, it should work.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
On Thursday, 21 August 2014 at 10:20:24 UTC, Weaseldog wrote:On Thursday, 21 August 2014 at 08:50:50 UTC, BlackEdder wrote: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.On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided. So, yes, it should work.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
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
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=5003Very 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
On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:This way all sorts of compilers and maybe IDEs would benefits/compilers/editors
Sep 03 2014
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
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:https://github.com/Hackerpilot/DCD/issues/85Wouldn'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 actuallybenefits 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
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: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.On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote:https://github.com/Hackerpilot/DCD/issues/85Wouldn'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 actuallyAs 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.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
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=5003Can 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
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: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.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=5003Can 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
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: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.On Wednesday, 3 September 2014 at 19:38:44 UTC, Idan Arye wrote: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.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=5003Can 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 08 2014
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
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=5003I 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
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: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.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=5003I 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 14 2014
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: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!On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye wrote: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.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=5003I 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 14 2014
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: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).On Sunday, 14 September 2014 at 03:22:35 UTC, Andrei Amatuni wrote: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!On Saturday, 13 September 2014 at 15:19:56 UTC, Idan Arye wrote: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.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=5003I 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 14 2014
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
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
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:It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".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 28 2014
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: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.jsonOn Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".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 29 2014
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:Seems a little weird to do so, considering that DUB itself does not look up in the directory tree...On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote: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.jsonOn Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".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 30 2014
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: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 :)On Sunday, 28 September 2014 at 11:51:21 UTC, Idan Arye wrote:Seems a little weird to do so, considering that DUB itself does not look up in the directory tree...On Thursday, 25 September 2014 at 15:40:22 UTC, John Colvin wrote: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.jsonOn Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:It looks for a file named "dub.json" in the current folder. If it can not find it, it looks for "package.json".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 30 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...
Sep 30 2014
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: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=5003True, 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...
Oct 04 2014