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

Reply via email to