digited wrote:

> Walter Bright �����:
>> The nice thing about an xml file is while D is relatively easy to parse, xml is trivial.
> 
> Why file? An IDE can call compiler process and get output with info from stdout, that will be much faster, and if IDE will need to store the info, it will, or will not, itself.

Yes please make it write to stdout!

This is a very good plan and useful not only for IDE's, but also for example to automate bindings to scriptings languages.

Walter Bright wrote:

...
> 
> Think of what it provides as very similar to what ddoc does, except that instead of being in a human-readable format it would be a machine-readable one.
> 
> In other words, for each module you'll be able to get
> 
> . all the symbols in that module, and the members of those symbols
> (recursively)
> . the file/line of the source location of each symbol
> . the ddoc comment for each symbol
> . the type of each symbol
> 
> Things could be added over time, I was just thinking of this for starters.

What about file/line/column of the symbol? Is this much work / hard work to add?

Walter Bright wrote:
> Jeremie Pelletier wrote:
>> The IDE usually keeps the files in memory and could therefore just call something like getSemantics(char** fileBuffers, int* fileSizes, int nFiles, ParseNode* parseTree) and have its parse nodes already allocated in process memory ready for use.
>>
>> Considering a lot of IDEs like to re-parse the current file every time the keyboard is idle for a few seconds, this could really help performance, nothing is more annoying than an IDE that feels unresponsive.
> 
> ...
 >
> Experience also suggests that using fork/exec rather than a shared dll approach is much more robust and easier to develop. The reason is that the former uses separate processes, which cannot step on each other. The latter puts everything in one process space, where you've got all the lovely, time-consuming, hair-pulling concurrency problems. The utter failure of the parse process also cannot bring down the IDE.

	Plus, with a DLL you're contaminated by the GPL: the IDE *has* to
be GPL-compatible to use your DLL. With fork/exec there are no such
constraints...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Walter Bright wrote:
> Think of what it provides as very similar to what ddoc does, except that instead of being in a human-readable format it would be a machine-readable one.
> 
> In other words, for each module you'll be able to get
> 
> . all the symbols in that module, and the members of those symbols (recursively)

	Including local variables for functions?

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Lutger wrote:
> What about file/line/column of the symbol? Is this much work / hard work to add? 

file/line of course, but I don't see a point to column.

Jérôme M. Berger wrote:
>> . all the symbols in that module, and the members of those symbols (recursively)
> 
>     Including local variables for functions?

That seems pointless, as they'll be inaccessible outside of the scope of the function.

Walter Bright wrote:
> In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important.
> 
> It's the IDE.
> 
> They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion).
> 
> So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file.
> 
> The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax.
> 
> What do you think?

How well will this work with partially parsable files? Will it recover and continue parsing the rest of the file, so all the gained data is still there in the rest of the file, or will it give an error and make the rest of the file lack autocompletion? Or is the idea to merge the newly parsed output with an old version so everything still has autocompletion but the line in question has an error?

Will it be possible to pass individual statements (maybe along with a previous symbol table) to dmd to save reparsing the whole file?

Other than that is sounds like a great idea, I can't wait for someone to write an omnicompletion plugin for vim using this!

Walter Bright schrieb:
> They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive?

If you use Eclipse for Java, you have:
- Debugger in place
- Automatic builder, compile on save
* Jump to line from error list
* Jump to declaration
- Show JavaDoc in tooltip, even in autocompletion
- Show hierarchy tree
- Autocompletion
- Quick assist, e.g.
	- assign ctor parameter to new field
	- extract selected text into local variable
	- Mark source portion, extract to method, the IDE evaluates the needed
parameters and return value
	- ...
There is so much more. But the main thing is, you are not only able to
use grep and friends on the pure text level. With an IDE you have
semantic support. This makes refactoring your code so much easier. You
can say "rename this method" and it works, all references to this method
are also altered. "Move this inner class to a top level class in that
package", "Derive from that class, yes add the needed ctors". There is
even an API to automate refactorings.

I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:has92u$1vum$1@digitalmars.com...
> Lutger wrote:
>> What about file/line/column of the symbol? Is this much work / hard work to add?
>
> file/line of course, but I don't see a point to column.

So the IDE knows where it is and can actually do things with it, instead of just knowing "Well, it's somewhere around here-ish."

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:has947$1vum$2@digitalmars.com...
> Jérôme M. Berger wrote:
>>> . all the symbols in that module, and the members of those symbols (recursively)
>>
>>     Including local variables for functions?
>
> That seems pointless, as they'll be inaccessible outside of the scope of the function.

void foo()
{
   int bar;
   // big complex func here
}
User: Ok, IDE, Refactor->Rename->foo's "bar" to "baz"