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.
