I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner.

I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request.

[1] https://github.com/Hackerpilot/DCD
[2] https://github.com/nsf/gocode

On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote:
> I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner.
>
> I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request.

Sounds like a great idea. Perhaps it's easier if you tell us which editor(s) you're planning to adopt, if any.

--
/Jacob Carlborg

On Friday, 9 August 2013 at 10:35:17 UTC, Jacob Carlborg wrote:
> On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote:
>> I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner.
>>
>> I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request.
>
> Sounds like a great idea. Perhaps it's easier if you tell us which editor(s) you're planning to adopt, if any.
>
> --
> /Jacob Carlborg

I'll look into kate. Can't promise anything due lack of time though. But it's something I'd benefit directly from, so .. :-)

> I'll look into kate. Can't promise anything due lack of time though. But it's something I'd benefit directly from, so .. :-)
> 

I really hope this will work for Kdevelop, too!

On Friday, 9 August 2013 at 11:00:36 UTC, David wrote:
>> I'll look into kate. Can't promise anything due lack of time though. But
>> it's something I'd benefit directly from, so .. :-)
>> 
>
> I really hope this will work for Kdevelop, too!

After one minute of api docs: It's an interface to KTextEditor, so it should somehow :-)

On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote:
> I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner.
>
> I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request.
>
> [1] https://github.com/Hackerpilot/DCD
> [2] https://github.com/nsf/gocode

I wrote the Vim script for your Dscanner, so it shouldn't be a problem to copy it and convert ti to use DCD.

But before I do that, I need you to implement a very important functionality that Dscanner has - the ability to take input from SDTIN. Without this, we would have to save the source file before we can query it - and saving the file is not something an autocompletion feature should do...

It would also be nice to be able to trick DCD into thinking that the data it got from STDIN is actually the content of the unsaved source file. I don't think it should affect the results now, but it might have impact on features you will add in the future, and I think all editors should support it before those new features come out.


Anyways, I think such a project should be integrated with a build system, so it could take the import information(and maybe some other data) from there.

On Friday, 9 August 2013 at 21:47:33 UTC, Idan Arye wrote:
> I wrote the Vim script for your Dscanner, so it shouldn't be a problem to copy it and convert ti to use DCD.
>
> But before I do that, I need you to implement a very important functionality that Dscanner has - the ability to take input from SDTIN. Without this, we would have to save the source file before we can query it - and saving the file is not something an autocompletion feature should do...

That was one of the several things that I have planned that I hadn't gotten to yet. It's on Github now.

> It would also be nice to be able to trick DCD into thinking that the data it got from STDIN is actually the content of the unsaved source file. I don't think it should affect the results now, but it might have impact on features you will add in the future, and I think all editors should support it before those new features come out.

Right now the file name wouldn't change anything. When it does, I'll add an option for it.

> Anyways, I think such a project should be integrated with a build system, so it could take the import information(and maybe some other data) from there.

Which one? I'd rather have the editor integration module figure that out and pass the correct -I options.

For Vim, integration with the YouCompleteMe[1] plugin would be a great
option (if I may say so myself). YCM offers a Completer API which can be
used to connect a semantic completion engine for any language. It already
has semantic completion support for C, C++, ObjC, ObjC++ (all through
libclang), Python (through Jedi), C# (through OmniSharp) etc.

When DCD becomes stable (is it already?) I'll gladly write the integration
for YCM.

[1]: https://github.com/Valloric/YouCompleteMe


On Fri, Aug 9, 2013 at 4:07 AM, Tobias Pankrath <tobias@pankrath.net> wrote:

> On Friday, 9 August 2013 at 11:00:36 UTC, David wrote:
>
>> I'll look into kate. Can't promise anything due lack of time though. But
>>> it's something I'd benefit directly from, so .. :-)
>>>
>>>
>> I really hope this will work for Kdevelop, too!
>>
>
> After one minute of api docs: It's an interface to KTextEditor, so it should somehow :-)
>

On Saturday, 10 August 2013 at 18:28:36 UTC, Val Markovic wrote:
> For Vim, integration with the YouCompleteMe[1] plugin would be a great
> option (if I may say so myself). YCM offers a Completer API which can be
> used to connect a semantic completion engine for any language. It already
> has semantic completion support for C, C++, ObjC, ObjC++ (all through
> libclang), Python (through Jedi), C# (through OmniSharp) etc.
>
> When DCD becomes stable (is it already?) I'll gladly write the integration
> for YCM.
>
> [1]: https://github.com/Valloric/YouCompleteMe

I think at this point the command line interface is fairly stable, but I wouldn't call the program itself stable.

On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote:
> I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner.
>
> I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request.
>
> [1] https://github.com/Hackerpilot/DCD
> [2] https://github.com/nsf/gocode

I can build the client just fine, but I get errors when I try to build the server:


acvisitor.d(107): Error: no property 'startLocation' for type 'stdx.d.ast.EnumBody'
acvisitor.d(108): Error: no property 'endLocation' for type 'stdx.d.ast.EnumBody'
acvisitor.d(107): Error: no constructor for Scope
acvisitor.d(138): Error: no property 'location' for type 'stdx.d.ast.Constructor'
autocomplete.d(252): Error: no property 'setTokens' for type 'Parser'
autocomplete.d(253): Error: struct stdx.d.parser.Parser member isSliceExpression is not accessible
autocomplete.d(268): Error: no property 'setTokens' for type 'Parser'
autocomplete.d(270): Error: struct stdx.d.parser.Parser member isSliceExpression is not accessible
autocomplete.d(83): Error: template instance autocomplete.setCompletions!(SortedRange!(const(Token)[], "a < b")) error instantiating
../dscanner/stdx/d/parser.d(386): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(401): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(415): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(429): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(448): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(462): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(476): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(490): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(504): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(522): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(536): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(550): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(587): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(607): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(621): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(3640): Warning: statement is not reachable
../dscanner/stdx/d/parser.d(5606): Warning: statement is not reachable


Since the `EnumBody` class is defined in Dscanner, I'm gonna take a wild guess and say you need to do some pushing to Dscanner.

DCD depends on Dscanner's source, so wouldn't it be a better idea to include it as a submodule? Event if you are developing them in parallel, and modifying Dscanner's source all the time to suit DCD's needs, you can use two build scripts - one that takes Dscanner from the parallel directory and used actively during the development, and one that takes it from the submodule and only used before a release\push to make sure other people can build it too.