On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
> Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then!

Some additional thoughts:

All you need to specify at startup are include paths and some completion options or so.
Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache.
These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box.

Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document.

What do you think about this idea?

On 26.01.2013 13:09, alex wrote:
> On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
>> Concerning completion server...why not a completion server? :D - I
>> mean, it'll be launched as soon as VisualD launches..and then you can
>> pipe-through commands etc. to interact like it's done the mspdbsrv
>> already. That's imho even easier than using COM + can be driven even
>> as a web server..which would be a real dream then!
>
> Some additional thoughts:
>
> All you need to specify at startup are include paths and some completion
> options or so.
> Then while editing, you either pass changes incrementally or push the
> entire document content to the server. The server parses that document
> then and updates the internal parse cache.
> These parse caches will be used for completion then. As you request e.g.
> the completion window to open or some tooltip info, you just pass the
> module name, the caret location and a command to the server - it'll
> answer then with all the items that shall be shown in the completion
> list or in the tooltip box.
>
> Furthermore, stuff like indenting and formatting could be interfaced,
> too - just push the document content, and it'll pass you back all
> changes to do OR the complete document.
>
> What do you think about this idea?

That's actually what the Visual D semantic server process does.

Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast.

Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle.

On Saturday, 26 January 2013 at 12:28:11 UTC, Rainer Schuetze wrote:
>
>
> On 26.01.2013 13:09, alex wrote:
>> On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
>>> Concerning completion server...why not a completion server? :D - I
>>> mean, it'll be launched as soon as VisualD launches..and then you can
>>> pipe-through commands etc. to interact like it's done the mspdbsrv
>>> already. That's imho even easier than using COM + can be driven even
>>> as a web server..which would be a real dream then!
>>
>> Some additional thoughts:
>>
>> All you need to specify at startup are include paths and some completion
>> options or so.
>> Then while editing, you either pass changes incrementally or push the
>> entire document content to the server. The server parses that document
>> then and updates the internal parse cache.
>> These parse caches will be used for completion then. As you request e.g.
>> the completion window to open or some tooltip info, you just pass the
>> module name, the caret location and a command to the server - it'll
>> answer then with all the items that shall be shown in the completion
>> list or in the tooltip box.
>>
>> Furthermore, stuff like indenting and formatting could be interfaced,
>> too - just push the document content, and it'll pass you back all
>> changes to do OR the complete document.
>>
>> What do you think about this idea?
>
> That's actually what the Visual D semantic server process does.

Lol.
>
> Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast.

Isn't there any integrated lexing done by the VS editor component? MD as well as #develop provide simple syntax definitions. But well, semantic type highlighting..yeah, this could be an issue - whereas..this process takes only 1 ms or so in D-IDE, so this shouldn't be a problem.

> Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle.

This wouldn't be a problem: There already is a strict separation of global (phobos, tango, vibe.d) and local (project, project-specific include) module sets in the parse cache. As I already said, changes to single documents could be passed to a document 'mirror' in the completion server immediately.
Wait, the same file might be used with different settings? Hehe, there actually are no settings for parsing and code completion. Anyway, why should two projects make use of two files? Even if, this wouldn't be any reason to turn mad - the AST was just stored in two parse caches then, so no problem at all :)

On 25/01/2013 13:43, Jacob Carlborg wrote:
> On 2013-01-25 13:01, Bruno Medeiros wrote:
>
>> If I was going with that approach I likely would rather port the MonoD
>> parser since it looks just as good, if not better, and C# would be
>> easier to port to Java than D.
>> But the descent.compiler experience (parser ported from DMD's parser)
>> put me off that approach of porting from a parser in another language
>> (although the VisualD parser might have less shortcomings than using the
>> DMD parser since at least VisualD's parser is designed for IDE use). I
>> want to have more control over the parser, and be able to effect my own
>> changes in it (something tricky if you're porting - unless you give up
>> the porting at some point, and just fork your own version and use ir
>> from there)
>
> I didn't say anything about porting :) I was suggesting you integrate
> the VisualD parser without porting it. That's why I suggested the one in
> VisualD and not the one in Mono-D.
>

Ah, fair enough. Yes, that could be an approach, although I dread a bit the thought of having to interface D data to Java through a C API... it might work though if one is carefull and manages to keep the interfacing data simple enough (and leave the complex stuff in their own language realm).

But to be honest, the main reason that keeps me from that approach, is that I feel I'm far more productive with Java than with D at the moment. Mostly because not of the language itself, but the excellent IDE semantic functionality, and debugger functionality, that Java has available. So yeah, kinda of a bootstrapping problem. :)

-- 
Bruno Medeiros - Software Engineer

On 2013-01-29 13:34, Bruno Medeiros wrote:

> Ah, fair enough. Yes, that could be an approach, although I dread a bit
> the thought of having to interface D data to Java through a C API... it
> might work though if one is carefull and manages to keep the interfacing
> data simple enough (and leave the complex stuff in their own language
> realm).
>
> But to be honest, the main reason that keeps me from that approach, is
> that I feel I'm far more productive with Java than with D at the moment.
> Mostly because not of the language itself, but the excellent IDE
> semantic functionality, and debugger functionality, that Java has
> available. So yeah, kinda of a bootstrapping problem. :)

Hehe, yeah, it's kind of the chicken and egg problem.

-- 
/Jacob Carlborg