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 :)
