Re: IDE

[Oleh Krehel]

Dmitry Gutov <address@hidden> writes:

> Not sure how looking at Atom would help, but you should absolutely try
> it. It's Free Software, after all.

Thanks for mentioning that. I wasn't sure that was the case.

>> Here's what (semantic-fetch-tags) returns:
>>
>> ...
>> A similar data structure *has* to be somewhere in the GCC innards: it's
>> a first step for compilation. In addition, this information is used to
>> point out compilation errors/warnings.
>> This data structure would know all defined functions/variables/types.
>> For instance, it would know that the class QPushButton is defined in
>> qpushbutton.h at line 57, and it inherits from QAbstractButton.
>
> You have to find out what the type of the call target is, first.
>
> In your example, it's rather easy: "QPushButton quit" is right on the
> previous line.
>
> But what if we're at the end of a chain of calls, like
>
> app->window->resolve_handler(bar).|
>
> ?
>
> And resolve_handler is overloaded, and its return type is dependent on
> the type of its argument?

CEDET already resolves these complicated chains pretty well, as long as
it's got the correct AST.

> What if `bar' is declared as `auto' (see C++11)? Or `app' itself?

This would be harder, but still very doable, even within CEDET.

Now, there are several issues standing in the way of getting the correct
AST:

1. Finding where the relevant headers are located on the file
system. This means that the AST parser should hook into the currently
used build system, and correctly see which #ifdef switches apply where.
Only GCC or its likes have access to this info always. To reiterate, if
the program compiles with GCC, the exact same switches must be passed to
the AST parser, so that it parses exactly the same headers in exactly
the same way.

2. Parsing the newly introduced language features. Here CEDET and
cc-mode are behind because of the shear complexity of the full C++
syntax. However, GCC does it very well.

I've been working on function-args.el to extend CEDET C++ support for my
uses for around 2 years now. The most common error that I have to work
around is "Type definition not found", which happens either because the
header path wasn't resolved, or the wrong #ifdef path was taken.

And, of course, there's the issue of Elisp speed. While jumping to a C
tag in emacs/src, I collect the tags from 190 files in that
directory. They are all pre-parsed by CEDET, totaling to 19460 tags. It
takes more than a full second to just merge these 190 lists retrieved
for each file into a single list. It makes me think that maybe that list
should be built in an external process.
On the other hand, having the full info in Elisp data structures would
ease the application development significantly.

    Oleh