Re: IDE

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 10 Oct 2015 11:59:34 +0300
> 
> On 10/10/2015 11:30 AM, Eli Zaretskii wrote:
> 
> > I was talking about working on IDE, not on completion.  And for the
> > most popular languages in the industry, not just for some a few niche
> > languages.
> 
> You quoted the message that said "accurate code completion and powerful 
> refactoring support".

No, I responded to a response.  The origin was this:

> If it falls short compared with other IDEs, I think this would be a
> great area for improvement of Emacs.

IOW, the issue is making Emacs a good IDE in general, including
features for browsing code, refactoring, debugging, and all the other
features users expect from a modern IDE.

Come to think of that, even coming up with a list of such features
would be real progress, as I don't think we have that, or ever had.

> I can agree that the latter is barely touched (*), 
> but it looked like you ignored the former.

I didn't ignore that.  I just don't see an effort to make Emacs a
modern IDE.  Working on separate parts of that in separate
uncoordinated activities is not the way we should pursue this, IMO.
It's inefficient at best, and at worst will end up with those
uncoordinated parts falling into oblivion when their driving forces
move on.

> > Let's not reiterate past discussions: you forget CEDET.
> 
> I was enumerating external programs. But sure, CEDET is a yet another 
> option for completion. Though not too "accurate" one, if we're talking 
> anything but C.

It needs to be actively developed.  Much more actively than it is now.

> > And if anyone _really_ cares about supporting C/C++, they should be
> > working with and on GCC's libcc1, which is available for quite some
> > time already.
> 
> I wasn't aware of it. Is its API stable?

I don't know.  It's for someone who will work on this to find out.  I
know that a motivated individual in the GDB development team already
based a useful set of commands on it -- you can compile and inject
code into your program while debugging it.

> Is it a good-enough replacement for libclang for the purposes of
> completion?

I don't know.  If it isn't, then the team who will work on the Emacs
IDE will have to take care of extending libcc1 as well, or find
someone with the GCC team to do that.  Exactly like that GDB developer
did when he needed features that were missing: he implemented them
himself, with guidance from GCC developers.

> > I expect to see a coherent, orchestrated effort towards having an IDE
> > mode in Emacs.  I don't see it, certainly not in discussions on this
> > list.  I also don't see any commits that would provide evidence of
> > such an effort.
> 
> We definitely could have more in this department, yes. But what would 
> you even call an "IDE mode"? A fixed multi-window setup a la ECB?

I don't know, and neither do we as a project.  A useful step would be
to produce a detailed answer to that question.  That answer could both
serve as base for useful discussions, and might provide some anchor
for all those external packages you mentioned to target some coherent
vision.

> I prefer to approach this problem from the bottom - like adding new 
> commands that perform certain advanced functions.

I don't believe comprehensive features such as IDE can be developed
exclusively bottom up.  There should be some basic set of assumptions
and design rules/decisions that everyone should target and abide by.
There should also be some unified leadership.

> > If such activities happen somewhere else, I would suggest their
> > participants to come here and work with and within the core.
> 
> That's... unlikely. At least, for most of them. My guess is that the 
> mailing list interface is off-putting, but maybe we just need a better 
> "community outreach" program, or something like that.

When the work begins in earnest, discussions are rarely needed, except
for discussing some very important design decisions.  Most of the time
you just develop your corner.

Lots of discussions about some feature is IME the first sign that no
one is actually working on it in any serious way.

I remember the beginning of the bidi development: it started by a few
years of discussions (on a separate mailing list) that led nowhere,
and most of them didn't even contribute any useful ideas for what
eventually became the implementation we now have in Emacs.  Once I
started to actually work on this, there was a small number of threads
(maybe 5) here, when I felt I needed to share my main design decisions
and get some feedback.

> That would be something for the new maintainer(s) to consider.

Indeed.

> > For
> > starters, I don't imagine they would succeed without some significant
> > changes and additions in the core infrastructure.  The place to
> > discuss that is here.
> 
> For refactoring, yes. But just "accurate code completion", without 
> extras like expanding the arguments or displaying the method source, can 
> be (and is, in certain packages) implemented though the 
> completion-at-point-function interface, present in Emacs since 24.1.

We didn't even decide that we want that as our mechanism.  Did anyone
consider how this compares with what the other modern IDEs offer?
What if we build our completion on a UI that today's developers will
dislike?  Unlike with many traditional Emacs features, which were
developed when there was no prior art, the IDE features have lots of
prior art.  No need to invent the wheel, just implement similar look
and feel.

> > Then what exactly is the nature of your objections to my observations?
> > It seems we agree on the bottom line: no one works on this.  The
> > reasons are immaterial.
> 
> If anything, my view of the situation is a lot brighter than yours.

I'll be happy to stand corrected.  Unfortunately, I don't yet see any
significant changes in the right direction, so my pessimism is for now
at least as justified as your optimism.