Re: IDE

[Dmitry Gutov]

On 10/18/2015 08:12 PM, David Engster wrote:

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

Thanks a lot, that should be very helpful. I have their Community 
Edition installed and try it out from time to time, but I haven't looked 
into their documentation, and this looks pretty good.

> 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.

I really think we should move CEDET to ELPA. It can allow you to keep 
the users up-to-date more easily, and would make cedet-devel-load.el 
unnecessary. The standard of what we're "allowed" to distribute, is also 
a bit more lax there, in practice.

But if it turns out to be a problem, as long as the compilation database 
is pluggable, you could extract it into a new package and let users 
install it from MELPA, until the policy here gets with the times.

> 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.

Yes. The "project system" I'd expect from Emacs is pretty different. A 
lot of users have lived with a "lightweight" one (Projectile) for years, 
so I try to approach the subject in project.el also from that direction.

> 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.

I'd say drop it, but you might have users depending on it.

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

But you can also create a specialized project implementation that knows 
how to read e.g. include paths from a project file, right?

> 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?

I always thought that magic-mode-alist takes action only after no 
matches in auto-mode-alist have been found. Maybe that's a worthwhile 
change to make.

Or add a new, third variable, meta-magic-mode-alist, that would take 
action after auto-mode-alist, when the fundamental mode is picked.