Re: IDE

[David Kastrup]

Eric Ludlam <address@hidden> writes:

> On 10/13/2015 12:28 PM, David Kastrup wrote:
>> "John Wiegley" <address@hidden> writes:
>>
>>>>>>>> Lluís  <address@hidden> writes:
>>>
>>>> Eli Zaretskii writes:
>>>> [...]
>>>>>> For C/C++, the community has Irony and Rtags, both based on libclang. If
>>>>>> libclang is unacceptable for you, you probably know a more appropriate
>>>>>> mailing list to bring that up at.
>>>
>>>>> Let's not reiterate past discussions: you forget CEDET.
>>>
>>> CEDET first came out in 2003. If it were the answer to our present
>>> questions, we would not be asking them.
>>
>> But since it did come out in 2003, we really should be asking _why_ it
>> isn't the answer to our present questions, in order to avoid the effort
>> of creating CEDET2 and CEDET3.
>
> Based on the many emails I've seen on the topic, I suspect the answer is:
>
> * It is hard to configure (ie - setting up project files,
>   include paths, or whatever.)
> * Specific implementations are incomplete (ie - c++ || other parser is
>   imperfect, the project system doesn't implement some feature, etc)
> * It is compared against better staffed tools

I got rid of it because it tended to eat all my CPU repeatedly digging
through buffers and files in the background.  I don't want some tool to
go treasure-hunting for hours in my directories without concrete cause,
then restart for inscrutable reasons.

It had its own idea of projects not matching the projects I was working
with, and it's an absolute no-go for Emacs to meddle with project
organization: I want to be able to jump in with Emacs into any project
without any pre- or post-configuration.

Maybe that's a decisive difference between what people got to expect
from an IDE and I expect from Emacs: if someone develops stuff in Visual
C++, everybody in the project is expected to use the project
organization tools of the Visual C++ IDE.  But I don't want my choice of
Emacs as an editor bleed all over a project.

Now you'll say that EDE (or Semantic, or whatever other component) is
entirely optional but it's hard to figure out just what the relations of
the various parts of CEDET are.  If you want to just work with the code
you have and not get stuff messed up, at some point of time it's easier
to just forego the whole inscrutable package and simplify one's life.

Again, that's a main difference to what a normal IDE is doing: it tends
to focus on a small set of languages and does them well when I buy into
the IDE, and I can use IDE features as needed.

But my buy-in was to Emacs.  I don't want to buy into a competing
framework CEDET.  If I want completion, I enable an option or package
for it, and I don't want it to come with a host of things I have no idea
how to keep from messing with my work environment.  It's nice when there
is some framework with which major mode writers can easily provide a lot
of functionality commonly expected of IDEs.  But CEDET appears to be
mainly a user choice, and it leaves the user with the job of maintaining
Emacs/CEDET integrity for his workflows.

And it did not particularly help that seminal parts of CEDET like its
parser generators were kept out of Emacs for very, very long: you needed
to install a third-party CEDET in order to even be able to maintain some
Emacs-internal modes.

-- 
David Kastrup