Re: IDE

[David Engster]

Dmitry Gutov writes:
>> Well, it's not like a bunch of people are hacking on the C
>> parser. Several things happened:
>
> It's not like I'm blaming anyone, really. But it leaves an impression
> of CEDET being more of a research project.

It leaves the impression of an understaffed project.

> I'm sure that's not all they have. They have completion, and they have
> (at least some kind of) refactorings using the same interface across
> products. That hints at flexible coupling between components.

It's not a secret:

http://www.jetbrains.org/intellij/sdk/docs/reference_guide/custom_language_support.html

I haven't looked at it in detail, but it looks familiar to me.

>> Ever tried to load some random make-based C++ project into Visual C++?
>
> It probably won't work. But so what? It's great that you have a
> solution for this in CEDET,

We don't. Makefiles are way too complex. The best solution IMHO is using
compilation databases, and EDE upstream has support for them. Of course,
it's another LLVM thingy, so I'm not sure if I'm allowed to merge it.

> but it shouldn't impose particular constraints on what a project API
> should look like. At least I don't see why or how it should.

My point is that people say they want an Emacs to be an "IDE", but at
the same time they don't want to be restricted in their Emacs usage, and
rightfully so. A typical IDE like Visual C++ forces you into using their
project system, otherwise nothing will work. So people want
IDE-features, but at the same time they want all the freedom Emacs
allows. And that's what CEDET tries to support.

Eric started with EDE as a project system similar to other IDEs, that
means you can start a project from scratch with EDE and it will manage
the build for you by generating a Makefile. While technically
impressive, I never liked this kind of project system, and honestly, I
think we should probably drop that part from EDE. But you are not forced
to use it, because Eric also added a custom project detection that is
very flexible. But if you manage the build yourself, you have to specify
everything manually (include paths, used compiler, etc.).

It doesn't help that Emacs is a very conservative piece of software. A
good example was already given: C++ includes without an extension. By
default, Emacs will open such files in fundamental mode. The GNU libc
actually has local variables comments in their includes just for that
reason! But of course, Qt does not have those, so Emacs cannot parse
those files by default, and people complain about Semantic not parsing
anything. Any other C++ IDE will make that decision for you, but guess
what would happen if we simply modified people's auto-mode-alist?

-David