[Mono-D] v2.1.18 Parser/Completion/General fixes&improvements

[Bruno Medeiros via Digitalmars-d-announce]

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