www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D AutoCompletion: is ycmd integration valuable?

reply "rcorre" <ryan rcorre.net> writes:
For those who don't know, ycmd (https://github.com/Valloric/ycmd) 
is an editor-agnostic completion engine that aims to reduce a lot 
of the duplicate code written for handling autocompletions in 
different language/editor combinations.

A long time ago, there was a request to get D support integrated 
into ycmd:
https://github.com/Valloric/YouCompleteMe/issues/521

It was closed as DCD was not 'stable' at the time. After DCD 
became 'stable', it seemed there was nobody available to put 
together the ycmd integration.

Do people think there would be value in reviving this effort?

I was playing around with integrating D completion into YCMD, but 
I'm getting to the point where it is becoming non-trivial.

I'm mainly interested in autocompletion in Vim, which already 
works reasonably well with Dutyl (a plugin that, among other 
things, helps set up vim's omnifunc to use DCD).

Would it be worthwhile to try to move D completion forward by 
integrating DCD with ycmd, or is it just better to keep working 
on existing editor-specific solutions like Dutyl?
Apr 15 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/15/15 9:15 AM, rcorre wrote:

 For those who don't know, ycmd (https://github.com/Valloric/ycmd) is an
 editor-agnostic completion engine that aims to reduce a lot of the
 duplicate code written for handling autocompletions in different
 language/editor combinations.

 A long time ago, there was a request to get D support integrated into ycmd:
 https://github.com/Valloric/YouCompleteMe/issues/521

 It was closed as DCD was not 'stable' at the time. After DCD became
 'stable', it seemed there was nobody available to put together the ycmd
 integration.

 Do people think there would be value in reviving this effort?

 I was playing around with integrating D completion into YCMD, but I'm
 getting to the point where it is becoming non-trivial.

 I'm mainly interested in autocompletion in Vim, which already works
 reasonably well with Dutyl (a plugin that, among other things, helps set
 up vim's omnifunc to use DCD).

 Would it be worthwhile to try to move D completion forward by
 integrating DCD with ycmd, or is it just better to keep working on
 existing editor-specific solutions like Dutyl?


I tried a while ago to setup DCD to be used in vim, with no success 
(even having Brian's ear at dconf to look at the issues, but he's not a 
vim guy).

IMO, the most useful improvement would be to make an easy-install 
package for DCD so it works with whatever editor the install is for. 
What that uses in the background, I couldn't care less :) So if ycmd is 
it, go for it. Just make it so I can install it easy!

-Steve
Apr 15 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 15 April 2015 at 14:05:32 UTC, Steven Schveighoffer 
wrote:

 On 4/15/15 9:15 AM, rcorre wrote:

 For those who don't know, ycmd 
 (https://github.com/Valloric/ycmd) is an
 editor-agnostic completion engine that aims to reduce a lot of 
 the
 duplicate code written for handling autocompletions in 
 different
 language/editor combinations.

 A long time ago, there was a request to get D support 
 integrated into ycmd:
 https://github.com/Valloric/YouCompleteMe/issues/521

 It was closed as DCD was not 'stable' at the time. After DCD 
 became
 'stable', it seemed there was nobody available to put together 
 the ycmd
 integration.

 Do people think there would be value in reviving this effort?

 I was playing around with integrating D completion into YCMD, 
 but I'm
 getting to the point where it is becoming non-trivial.

 I'm mainly interested in autocompletion in Vim, which already 
 works
 reasonably well with Dutyl (a plugin that, among other things, 
 helps set
 up vim's omnifunc to use DCD).

 Would it be worthwhile to try to move D completion forward by
 integrating DCD with ycmd, or is it just better to keep 
 working on
 existing editor-specific solutions like Dutyl?


 I tried a while ago to setup DCD to be used in vim, with no 
 success (even having Brian's ear at dconf to look at the 
 issues, but he's not a vim guy).

 IMO, the most useful improvement would be to make an 
 easy-install package for DCD so it works with whatever editor 
 the install is for. What that uses in the background, I 
 couldn't care less :) So if ycmd is it, go for it. Just make it 
 so I can install it easy!

 -Steve


DCD has been usable from vim for a looong time, when was the last 
time you tried?
Apr 15 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/15/15 10:47 AM, weaselcat wrote:


 DCD has been usable from vim for a looong time, when was the last time
 you tried?


Dconf 2014.

I'm sure with more elbow grease I could get it to work. But I shouldn't 
have to ;) Give me a dmg that I can drag or script that I can run, I'm good.

-Steve
Apr 15 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 15 April 2015 at 15:12:00 UTC, Steven Schveighoffer 
wrote:

 On 4/15/15 10:47 AM, weaselcat wrote:


 DCD has been usable from vim for a looong time, when was the 
 last time
 you tried?


 Dconf 2014.

 I'm sure with more elbow grease I could get it to work. But I 
 shouldn't have to ;) Give me a dmg that I can drag or script 
 that I can run, I'm good.

 -Steve


https://github.com/idanarye/vim-dutyl
have DCD in your path and it should work out of the box.
Apr 15 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/15/15 11:13 AM, weaselcat wrote:

 On Wednesday, 15 April 2015 at 15:12:00 UTC, Steven Schveighoffer wrote:

 On 4/15/15 10:47 AM, weaselcat wrote:


 DCD has been usable from vim for a looong time, when was the last time
 you tried?


 Dconf 2014.

 I'm sure with more elbow grease I could get it to work. But I
 shouldn't have to ;) Give me a dmg that I can drag or script that I
 can run, I'm good.


 https://github.com/idanarye/vim-dutyl
 have DCD in your path and it should work out of the box.


Thanks, I'll give it a try when I have some free cycles.

-Steve
Apr 15 2015
prev sibling next sibling parent reply "Israel" <tl12000 live.com> writes:
On Wednesday, 15 April 2015 at 13:15:31 UTC, rcorre wrote:

 For those who don't know, ycmd 
 (https://github.com/Valloric/ycmd) is an editor-agnostic 
 completion engine that aims to reduce a lot of the duplicate 
 code written for handling autocompletions in different 
 language/editor combinations.

 A long time ago, there was a request to get D support 
 integrated into ycmd:
 https://github.com/Valloric/YouCompleteMe/issues/521

 It was closed as DCD was not 'stable' at the time. After DCD 
 became 'stable', it seemed there was nobody available to put 
 together the ycmd integration.

 Do people think there would be value in reviving this effort?

 I was playing around with integrating D completion into YCMD, 
 but I'm getting to the point where it is becoming non-trivial.

 I'm mainly interested in autocompletion in Vim, which already 
 works reasonably well with Dutyl (a plugin that, among other 
 things, helps set up vim's omnifunc to use DCD).

 Would it be worthwhile to try to move D completion forward by 
 integrating DCD with ycmd, or is it just better to keep working 
 on existing editor-specific solutions like Dutyl?


Thats great and all but not everyone is autistic enough to learn 
the ins and outs of Vim or Emacs...

Visual Studio completion is very interesting as well because it 
can read the functions of other third party libraries 
automatically. Can ycmd do that?
Apr 15 2015
parent reply "rcorre" <ryan rcorre.net> writes:
 Thats great and all but not everyone is autistic enough to 
 learn the ins and outs of Vim or Emacs...

 Visual Studio completion is very interesting as well because it 
 can read the functions of other third party libraries 
 automatically. Can ycmd do that?


ycmd is intended to serve as a layer between a 
completion/semantic engine (DCD/Dscanner in this case) and an 
editor.
Reading third party library functions would be the job of DMD in 
this case (which it can do, if the paths are set up correctly).

The potential advantage of ycmd is better integration of that 
completion info within your editor.

At this point, dutyl does a good job, but there are definitely 
areas to improve.
Improving dutyl would involve duplicating some of ycmd's logic in 
vimscript, while proper ycmd integration would involve 
implementing some of dutyl's logic in python.
Apr 15 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 16 April 2015 at 01:55:09 UTC, rcorre wrote:

 Thats great and all but not everyone is autistic enough to 
 learn the ins and outs of Vim or Emacs...

 Visual Studio completion is very interesting as well because 
 it can read the functions of other third party libraries 
 automatically. Can ycmd do that?


 ycmd is intended to serve as a layer between a 
 completion/semantic engine (DCD/Dscanner in this case) and an 
 editor.
 Reading third party library functions would be the job of DMD 
 in this case (which it can do, if the paths are set up 
 correctly).

 The potential advantage of ycmd is better integration of that 
 completion info within your editor.

 At this point, dutyl does a good job, but there are definitely 
 areas to improve.
 Improving dutyl would involve duplicating some of ycmd's logic 
 in vimscript, while proper ycmd integration would involve 
 implementing some of dutyl's logic in python.


Some people - myself included - have already asked Brian to make 
DCD read the project's import paths from Dub or something. At 
first he claimed this is the editor's job - now he seems to be 
accepting the idea enough to accept a pull request - but he 
doesn't care about it enough to implement it himself.

I won't be doing it either, because Dutyl is already doing this 
job and feeding the import paths to DCD, I'm assuming the other 
editor plugins also have their solutions for that already, so you 
can count their maintainers out. You'll need someone new to have 
enough motivation to do it - someone who wants to develop a new 
editor plugin(or plugin for ymcd or 
https://github.com/quarnster/completion or other stuff like that) 
and is willing to contribute to DCD on the way.

A while back, I've looked a bit into integrating Dutyl with 
ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
and found out this connection is a waste of time, since I'll have 
to reimplement all the relevant parts in Python anyways so there 
is no point to make the semantic engine depend on Dutyl.
Apr 16 2015
parent reply "w0rp" <devw0rp gmail.com> writes:
On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or something. 
 At first he claimed this is the editor's job - now he seems to 
 be accepting the idea enough to accept a pull request - but he 
 doesn't care about it enough to implement it himself.

 I won't be doing it either, because Dutyl is already doing this 
 job and feeding the import paths to DCD, I'm assuming the other 
 editor plugins also have their solutions for that already, so 
 you can count their maintainers out. You'll need someone new to 
 have enough motivation to do it - someone who wants to develop 
 a new editor plugin(or plugin for ymcd or 
 https://github.com/quarnster/completion or other stuff like 
 that) and is willing to contribute to DCD on the way.

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways so 
 there is no point to make the semantic engine depend on Dutyl.


I had to do some work to get Syntastic, which I use for syntax 
checking in Vim, to get the import paths in there from dub. I 
actually raised an issue for dub recently requesting dub to get a 
command to ouptut the import paths for you. The discussion led to 
me bineg able to finish my program.

https://github.com/D-Programming-Language/dub/issues/542

My program can be seen here.

https://github.com/w0rp/vim/blob/master/dub_paths.d

It looks like Dutyl currently handles this by applying eval to 
the result of 'dub describe', then doing the rest in VimL.

I might move to using Dutyl, as I am not currently running 
DScanner on my projects, and I think it's time that I did. Using 
DCD would also be nice, and having documentation on symbols would 
be nice. There is a way to implement this in Vim for mouse 
hovers. I'm not sure if Dutyl handles this already.
Apr 16 2015
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:

 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or 
 something. At first he claimed this is the editor's job - now 
 he seems to be accepting the idea enough to accept a pull 
 request - but he doesn't care about it enough to implement it 
 himself.

 I won't be doing it either, because Dutyl is already doing 
 this job and feeding the import paths to DCD, I'm assuming the 
 other editor plugins also have their solutions for that 
 already, so you can count their maintainers out. You'll need 
 someone new to have enough motivation to do it - someone who 
 wants to develop a new editor plugin(or plugin for ymcd or 
 https://github.com/quarnster/completion or other stuff like 
 that) and is willing to contribute to DCD on the way.

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways 
 so there is no point to make the semantic engine depend on 
 Dutyl.


 I had to do some work to get Syntastic, which I use for syntax 
 checking in Vim, to get the import paths in there from dub. I 
 actually raised an issue for dub recently requesting dub to get 
 a command to ouptut the import paths for you. The discussion 
 led to me bineg able to finish my program.

 https://github.com/D-Programming-Language/dub/issues/542

 My program can be seen here.

 https://github.com/w0rp/vim/blob/master/dub_paths.d

 It looks like Dutyl currently handles this by applying eval to 
 the result of 'dub describe', then doing the rest in VimL.

 I might move to using Dutyl, as I am not currently running 
 DScanner on my projects, and I think it's time that I did. 
 Using DCD would also be nice, and having documentation on 
 symbols would be nice. There is a way to implement this in Vim 
 for mouse hovers. I'm not sure if Dutyl handles this already.


Dutyl doesn't support that mouse hovering feature that you want, 
and I don't have any plans to implement it, but if you want it 
you can implement it and send a PR.
Apr 16 2015
parent "w0rp" <devw0rp gmail.com> writes:
On Thursday, 16 April 2015 at 14:30:04 UTC, Idan Arye wrote:

 On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:

 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or 
 something. At first he claimed this is the editor's job - now 
 he seems to be accepting the idea enough to accept a pull 
 request - but he doesn't care about it enough to implement it 
 himself.

 I won't be doing it either, because Dutyl is already doing 
 this job and feeding the import paths to DCD, I'm assuming 
 the other editor plugins also have their solutions for that 
 already, so you can count their maintainers out. You'll need 
 someone new to have enough motivation to do it - someone who 
 wants to develop a new editor plugin(or plugin for ymcd or 
 https://github.com/quarnster/completion or other stuff like 
 that) and is willing to contribute to DCD on the way.

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways 
 so there is no point to make the semantic engine depend on 
 Dutyl.


 I had to do some work to get Syntastic, which I use for syntax 
 checking in Vim, to get the import paths in there from dub. I 
 actually raised an issue for dub recently requesting dub to 
 get a command to ouptut the import paths for you. The 
 discussion led to me bineg able to finish my program.

 https://github.com/D-Programming-Language/dub/issues/542

 My program can be seen here.

 https://github.com/w0rp/vim/blob/master/dub_paths.d

 It looks like Dutyl currently handles this by applying eval to 
 the result of 'dub describe', then doing the rest in VimL.

 I might move to using Dutyl, as I am not currently running 
 DScanner on my projects, and I think it's time that I did. 
 Using DCD would also be nice, and having documentation on 
 symbols would be nice. There is a way to implement this in Vim 
 for mouse hovers. I'm not sure if Dutyl handles this already.


 Dutyl doesn't support that mouse hovering feature that you 
 want, and I don't have any plans to implement it, but if you 
 want it you can implement it and send a PR.


Yeah, I was looking into it myself and thought, "Oh, that would 
be a nice addition." So I'll probably fork it at some point and 
submit a pull request.
Apr 16 2015
prev sibling next sibling parent reply "rcorre" <ryan rcorre.net> writes:
 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or 
 something. At first he claimed this is the editor's job - now 
 he seems to be accepting the idea enough to accept a pull 
 request - but he doesn't care about it enough to implement it 
 himself.




I kind of agree that this is not DCD's job. It seems like it is 
dub's job to provide a command that prints out the import paths 
in a ready-to-parse format (i.e. cleaner output than 'describe'). 
Well, maybe not _job_, but it would be nice.


On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:
My program can be seen here.

https://github.com/w0rp/vim/blob/master/dub_paths.d


Is there a blocker on getting something like this implemented as 
`dub --print-import-paths`?


 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways 
 so there is no point to make the semantic engine depend on 
 Dutyl.




Yeah, ycmd being editor agnostic means it can't rely on any vim 
functionality.
Glue logic that dutyl provides will have to be implemented on the 
ycmd end or the DCD end.
For example, right now I've (rather haphazardly) patched DCD to 
accept a line/column number instead of a byte offset (dutyl does 
this trivially with vim's line2byte).
Apr 16 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 16 April 2015 at 16:27:07 UTC, rcorre wrote:

 For example, right now I've (rather haphazardly) patched DCD to 
 accept a line/column number instead of a byte offset (dutyl 
 does this trivially with vim's line2byte).


I've avoided adding this features because byte offset is very 
exact. Column counts can be thrown off by tab width settings in 
some editors. Requiring that the lexer know the tab width before 
it even starts running is a bit of nonsense I'd prefer to not 
deal with.
Apr 16 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:

 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or 
 something. At first he claimed this is the editor's job - now 
 he seems to be accepting the idea enough to accept a pull 
 request - but he doesn't care about it enough to implement it 
 himself.

 I won't be doing it either, because Dutyl is already doing 
 this job and feeding the import paths to DCD, I'm assuming the 
 other editor plugins also have their solutions for that 
 already, so you can count their maintainers out. You'll need 
 someone new to have enough motivation to do it - someone who 
 wants to develop a new editor plugin(or plugin for ymcd or 
 https://github.com/quarnster/completion or other stuff like 
 that) and is willing to contribute to DCD on the way.

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways 
 so there is no point to make the semantic engine depend on 
 Dutyl.


 I had to do some work to get Syntastic, which I use for syntax 
 checking in Vim, to get the import paths in there from dub. I 
 actually raised an issue for dub recently requesting dub to get 
 a command to ouptut the import paths for you. The discussion 
 led to me bineg able to finish my program.

 https://github.com/D-Programming-Language/dub/issues/542

 My program can be seen here.

 https://github.com/w0rp/vim/blob/master/dub_paths.d

 It looks like Dutyl currently handles this by applying eval to 
 the result of 'dub describe', then doing the rest in VimL.

 I might move to using Dutyl, as I am not currently running 
 DScanner on my projects, and I think it's time that I did. 
 Using DCD would also be nice, and having documentation on 
 symbols would be nice. There is a way to implement this in Vim 
 for mouse hovers. I'm not sure if Dutyl handles this already.


Hi,
Try neomake[1], I wrote the checker for it - it will 
automatically detect of you're on a dub project and parse the dub 
describe output for includes.

Also, if you use neovim it runs in the background and is 
non-blocking.

I guess I shod make a blog post for setting up vim to use D ad 
I've seem a lot of trouble with it recently.

[1] https://github.com/benekastah/neomake?files=1
Apr 16 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 16 April 2015 at 18:37:41 UTC, weaselcat wrote:

 On Thursday, 16 April 2015 at 12:01:48 UTC, w0rp wrote:

 On Thursday, 16 April 2015 at 11:46:09 UTC, Idan Arye wrote:

 Some people - myself included - have already asked Brian to 
 make DCD read the project's import paths from Dub or 
 something. At first he claimed this is the editor's job - now 
 he seems to be accepting the idea enough to accept a pull 
 request - but he doesn't care about it enough to implement it 
 himself.

 I won't be doing it either, because Dutyl is already doing 
 this job and feeding the import paths to DCD, I'm assuming 
 the other editor plugins also have their solutions for that 
 already, so you can count their maintainers out. You'll need 
 someone new to have enough motivation to do it - someone who 
 wants to develop a new editor plugin(or plugin for ymcd or 
 https://github.com/quarnster/completion or other stuff like 
 that) and is willing to contribute to DCD on the way.

 A while back, I've looked a bit into integrating Dutyl with 
 ycmd(http://forum.dlang.org/thread/qsvrvtpqrdvfujahkccd forum.dlang.org?page=2#post-ahwguxayeamrvdczlac
:40forum.dlang.org) 
 and found out this connection is a waste of time, since I'll 
 have to reimplement all the relevant parts in Python anyways 
 so there is no point to make the semantic engine depend on 
 Dutyl.


 I had to do some work to get Syntastic, which I use for syntax 
 checking in Vim, to get the import paths in there from dub. I 
 actually raised an issue for dub recently requesting dub to 
 get a command to ouptut the import paths for you. The 
 discussion led to me bineg able to finish my program.

 https://github.com/D-Programming-Language/dub/issues/542

 My program can be seen here.

 https://github.com/w0rp/vim/blob/master/dub_paths.d

 It looks like Dutyl currently handles this by applying eval to 
 the result of 'dub describe', then doing the rest in VimL.

 I might move to using Dutyl, as I am not currently running 
 DScanner on my projects, and I think it's time that I did. 
 Using DCD would also be nice, and having documentation on 
 symbols would be nice. There is a way to implement this in Vim 
 for mouse hovers. I'm not sure if Dutyl handles this already.


 Hi,
 Try neomake[1], I wrote the checker for it - it will 
 automatically detect of you're on a dub project and parse the 
 dub describe output for includes.

 Also, if you use neovim it runs in the background and is 
 non-blocking.

 I guess I shod make a blog post for setting up vim to use D ad 
 I've seem a lot of trouble with it recently.

 [1] https://github.com/benekastah/neomake?files=1


Holy typos, I hate touchscreens :(
Apr 16 2015
prev sibling parent reply "rcorre" <ryan rcorre.net> writes:
On Thursday, 16 April 2015 at 18:37:41 UTC, weaselcat wrote:

 Hi,
 Try neomake[1], I wrote the checker for it - it will 
 automatically detect of you're on a dub project and parse the 
 dub describe output for includes.

 Also, if you use neovim it runs in the background and is 
 non-blocking.


I'm getting closer and closer to jumping on the neovim 
bandwagon...
I was never able to get vim-dispatch working properly.


 I guess I shod make a blog post for setting up vim to use D ad 
 I've seem a lot of trouble with it recently.


Please do. I'd especially like to hear about the use of 
makeprg/errorformat with regards to filtering dub output and 
jumping to assert failures.

On Thursday, 16 April 2015 at 18:29:26 UTC, Brian Schott wrote:

 I've avoided adding this features because byte offset is very 
 exact. Column counts can be thrown off by tab width settings in 
 some editors. Requiring that the lexer know the tab width 
 before it even starts running is a bit of nonsense I'd prefer 
 to not deal with.


Well, someone has to do the conversion.
But you're right, it should be the editor -- having DCD operate 
on byte offsets makes sense.
Unfortunately, the ycmd API asks for the line/col position from 
the editor (unless I'm missing something).
Maybe this is just a sign that ycmd is the wrong road to go down 
here, but I was hoping I could leverage some useful existing 
functionality in ycmd and hopefully get some better performance 
(completions provided via dutyl+DCD can take a noticeable amount 
of time on my older machine).
Apr 16 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 16 April 2015 at 21:02:29 UTC, rcorre wrote:

 On Thursday, 16 April 2015 at 18:37:41 UTC, weaselcat wrote:

 Hi,
 Try neomake[1], I wrote the checker for it - it will 
 automatically detect of you're on a dub project and parse the 
 dub describe output for includes.

 Also, if you use neovim it runs in the background and is 
 non-blocking.


 I'm getting closer and closer to jumping on the neovim 
 bandwagon...
 I was never able to get vim-dispatch working properly.


 I guess I shod make a blog post for setting up vim to use D ad 
 I've seem a lot of trouble with it recently.


 Please do. I'd especially like to hear about the use of 
 makeprg/errorformat with regards to filtering dub output and 
 jumping to assert failures.

 On Thursday, 16 April 2015 at 18:29:26 UTC, Brian Schott wrote:

 I've avoided adding this features because byte offset is very 
 exact. Column counts can be thrown off by tab width settings 
 in some editors. Requiring that the lexer know the tab width 
 before it even starts running is a bit of nonsense I'd prefer 
 to not deal with.


 Well, someone has to do the conversion.
 But you're right, it should be the editor -- having DCD operate 
 on byte offsets makes sense.
 Unfortunately, the ycmd API asks for the line/col position from 
 the editor (unless I'm missing something).
 Maybe this is just a sign that ycmd is the wrong road to go 
 down here, but I was hoping I could leverage some useful 
 existing functionality in ycmd and hopefully get some better 
 performance (completions provided via dutyl+DCD can take a 
 noticeable amount of time on my older machine).


What the ycmd API accepts is not the visual column but the "byte 
column" - how many bytes from the beginning of the line the 
cursor is placed. This means that if the semantic engine opens 
the file and reads it, it can calculate the byte offset from the 
line and "byte column" supplied to it - without caring about 
multibyte characters tab settings.
Apr 16 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Friday, 17 April 2015 at 00:08:51 UTC, Idan Arye wrote:

 What the ycmd API accepts is not the visual column but the 
 "byte column" - how many bytes from the beginning of the line 
 the cursor is placed. This means that if the semantic engine 
 opens the file and reads it, it can calculate the byte offset 
 from the line and "byte column" supplied to it - without caring 
 about multibyte characters tab settings.


The lexer used by DCD does track the byte columns of tokens.
Apr 16 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-15 15:15, rcorre wrote:

 For those who don't know, ycmd (https://github.com/Valloric/ycmd) is an
 editor-agnostic completion engine that aims to reduce a lot of the
 duplicate code written for handling autocompletions in different
 language/editor combinations.


Which editors are supported?

-- 
/Jacob Carlborg
Apr 15 2015
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 16 April 2015 at 06:23:50 UTC, Jacob Carlborg wrote:

 On 2015-04-15 15:15, rcorre wrote:

 For those who don't know, ycmd 
 (https://github.com/Valloric/ycmd) is an
 editor-agnostic completion engine that aims to reduce a lot of 
 the
 duplicate code written for handling autocompletions in 
 different
 language/editor combinations.


 Which editors are supported?


https://github.com/Valloric/ycmd#known-ycmd-clients
Apr 16 2015