[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDE
From: |
Eric Ludlam |
Subject: |
Re: IDE |
Date: |
Wed, 14 Oct 2015 08:05:15 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 10/14/2015 04:09 AM, David Kastrup wrote:
Eric Ludlam <address@hidden> writes:
On 10/13/2015 12:28 PM, David Kastrup wrote:
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.
Thanks for the diverse feedback.
The need to move your files into some new structure is something I've
always avoided. There is a "do it for you" project structure if you
don't care, and several other types that just uses what you have, and
can detect a bunch of variants without leaving its own files behind.
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
The puzzle for me here is that while the different pieces are
technically independent, the more complex tasks, such as completion,
depend on the other tools doing their job. Good smart completion
depends on a knowledge of a project's structure to find headers (C/C++),
and it also depends on rummaging around in your files to find the needed
symbols.
AFAIK, every smart completion engine out there has the same dependency.
There are plenty of others that don't, like Global which just finds
what's there and makes the most of it, but it isn't smart completion.
I suspect what you'd really like is to say "yeah, I'd like some smart
completion with a side of API doc", and have an auto-configure thingy do
the rest. Sounds great! To make that happen though, we need Emacs to
be taught how to detect your files and rummage through them to make it
happen. If you work on code of a style I or other contributors never
worked on, it probably isn't in CEDET.
Pulling in external tools like gcc, clang, whatever to do the work is a
great way to make that happen as it pushes the CPU work off of Emacs'
thread, and in some cases brings knowledge of the project along with
it. Doing that type of integration can be done with CEDET's framework,
or independent of it. I am not advocating to not do that type of
integration, but to consider doing it in CEDET's framework because:
a) it will be easier than starting from scratch
b) doesn't preclude other types of integration later
On 10/14/2015 06:47 AM, Dmitry Gutov wrote:
My already-stated impression is that it's over-specialized and tightly
coupled.
There are definitely dependencies. I don't think it is
over-specialized, but perhaps overly-generalized. Every layer was set
up so new languages, modes, projects, whatever can be slotted into the
system. The tendency is that many are not complete which lends itself
to disappointment. This is not uncommon in Emacs. There are lots of
modes floating around with no indentation, poor syntax tables and
incomplete highlighting.
Not saying that the problem domain is easy, but being able to use
different pieces of the solution separately would go a long way
towards alleviating the complaint that certain other parts are
incomplete.
I agree, this would be nice.
Especially if it were easier to swap in different solutions for some
of those parts (and do entirely without some others), and do that in
not too many lines, all as part of the user's configuration.
It is possible to swap in different solutions (under the CEDET
framework) but in many cases, there is currently only one solution.
In these conversations it is hard to distinguish if the (usually valid)
criticism are about CEDET the framework, or about various
implementations under CEDET.
It is also hard since I don't really have time to address the issues raised.
Eric
- Re: IDE, (continued)
- Re: IDE, LluĂs, 2015/10/13
- Re: IDE, John Wiegley, 2015/10/13
- Re: IDE, David Kastrup, 2015/10/13
- Re: IDE, John Wiegley, 2015/10/13
- Re: IDE, Eric Ludlam, 2015/10/13
- Re: IDE, John Wiegley, 2015/10/14
- Re: IDE, David Kastrup, 2015/10/14
- Re: IDE,
Eric Ludlam <=
- Re: IDE, Dmitry Gutov, 2015/10/14
- Re: IDE, Eric Ludlam, 2015/10/15
- Re: IDE, Dmitry Gutov, 2015/10/15
- Re: IDE, Eric Ludlam, 2015/10/15
- Re: IDE, Dmitry Gutov, 2015/10/16
- Re: IDE, Stephen Leake, 2015/10/14
- Re: IDE, David Kastrup, 2015/10/14
- Re: IDE, Dmitry Gutov, 2015/10/14
- Re: IDE, John Wiegley, 2015/10/16
- Re: IDE, Eli Zaretskii, 2015/10/17