On 05/09/2014 17:40, Alex wrote:
> On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote:
>> On 05/09/2014 07:32, Jacob Carlborg wrote:
>>> Perhaps I'm nitpicking but an external tools doesn't sound like a good
>>> idea. A completely separate library that can be shared among tools and
>>> be integrated into an IDE, absolutely yes. But not a tool.
>>
>> It's like it was said earlier, a library is easier to integrate, but
>> only if across the same language (for the code the library is written
>> in, and the code the IDE extensions are written in).
>
> Well, I spent a (very little though) time getting informed on how
> everything could be done using dcd-server running in the background.
>
> 1) the communication between dcd-server and dcd-client happens via tcp
> ipc. So extremely easy to implement
> 2) The currently edited module's text can be piped through that IPC
> channel to not have to query the hardware IO all the time.
> 3) My completion 'model' allows having individual import paths for each
> edited file, project, super-project aka solution. DCD seems not to
> support this atm(?).
> 4) D_Parser is heavily woven with all kinds of Mono-D features, so just
> ripping out the completion component and replacing it with dcd won't
> bring anything sustainable, since I'd still had to have raw access to
> all ASTs out there in order to e.g. display a 'breadcrumb' path bar on
> the editor's top, the doc outline, refactoring features etc. -- An
> entirely separate Mono-D is needed imho which probably only features
> basic projecting/build support as well as dcd bindings.
>
> Did you, Bruno, discarded your customly written completion framework in
> favor of dcd?

I didn't discard my completion engine, since from what I saw in DCD (at least at the time), DCD didn't seem better than mine (only Mono-D has that honor at the moment ;) )
So I'm keeping it, also because there are a lot of improvements I can make to DDT's completion engine with relative low effort (I just had my time caught up in other features to go into that).

Also, there were several limitations with the DCD protocol and/or options. First was lack of DUB support. Then, limited information on the resolved symbols (for example function symbols don't have the full function signature).
Then there was also the inability to perform completion with in-memory files. (At least using DCD-client. Are you saying what if the we communicate directly to DCD-server, that is possible? I haven't looked into that, only the README documentation of DCD)

I fixed most of these by rolling my own semantic daemon (note, it's not finished yet). Although, to be honest, even though I made an API that supports semantic operations in multiple in-memory files, after I saw Atila Neves lightning talk about fly-check in Vim, I'm fairly convinced just automatically writing all files to the disk would have been good enough, if not even better (I'm thinking the OS would cache the files, so I/O would not be an issue... but that premise would have to be tested)

The only significant issue is the same as you mentioned in 4) . I could shift all my semantic features to the daemon at this point, but I would still need a D parser as part of DDT for all the syntax features - the editor outline, code folding, the "breadcrumb", etc.. This functionality would have to be moved to the daemon so that the IDE could be completely free of any D parser or D engine. While that is certainly feasible, I wonder if there could be a significant performance hit: The semantic features (code complete, open definition) are only invoked sporadically, but parsing/syntax features require parsing on more or less every keystroke - so that info would have to be retrieved from the daemon nearly constantly, and would add some overhead... It's something to consider.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 2014-09-09 15:06, Bruno Medeiros wrote:

> Oh I see. Do people like this behavior BTW? Eclipse could also be
> configured to work like this, but I'm not sure I would like it, (even if
> there are no problems such as slow autocompletion.). But maybe it just
> cause I'm used to it.

I wouldn't mind having an option for it.

-- 
/Jacob Carlborg

On 09/09/2014 20:16, Jacob Carlborg wrote:
> On 2014-09-09 15:06, Bruno Medeiros wrote:
>
>> Oh I see. Do people like this behavior BTW? Eclipse could also be
>> configured to work like this, but I'm not sure I would like it, (even if
>> there are no problems such as slow autocompletion.). But maybe it just
>> cause I'm used to it.
>
> I wouldn't mind having an option for it.
>

It's already possible to do it (although not obvious at all). Just go to
Preferences/DDT/Editor/Content Assist and put the ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" string in the
Auto activation trigger characters field.

(It works for JDT too)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 2014-09-10 16:37, Bruno Medeiros wrote:

> It's already possible to do it (although not obvious at all). Just go to
> Preferences/DDT/Editor/Content Assist and put the
> ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" string in the
> Auto activation trigger characters field.
>
> (It works for JDT too)

It does? Haha, cool, I'll give it a try.

-- 
/Jacob Carlborg

On Tuesday, 9 September 2014 at 13:46:06 UTC, Bruno Medeiros wrote:
> The reason I ask is because there seems to be some functionality only present in dscanner that would be useful for IDEs too, such as "dscanner --declaration"

I added that feature because I wanted something usable from the command line that was more accurate than grep or ack. There's an enhancement request for adding something similar to DCD: https://github.com/Hackerpilot/DCD/issues/162.