Re: IDE

[Dmitry Gutov]

On 10/10/2015 12:40 PM, Eli Zaretskii wrote:

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

At least we "have volunteers" for that.

> It's inefficient at best, and at worst will end up with those
> uncoordinated parts falling into oblivion when their driving forces
> move on.

That would be accurate to say about projects at early stages of 
development, but the respective third-party packages already work now. 
If anything, we could keep them working, even Emacs undergoes large 
internal changes.

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

I suppose.

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

That seems orthogonal to code completion capabilities, for where I'm 
standing. But I'm not a good person to judge.

This does make a good material for a feature request for Irony, 
unfortunately. Someone more knowledgeable should do that instead.

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

"We need a common interface for refactoring tools" sounds like a good 
problem statement. I hope that capability can grow from the xref 
interface, but that needs more work and thought.

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

A comprehensive set of IDE features might be too lofty a goal for us, in 
the foreseeable future.

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

completion-at-point-functions is the API for backends to implement. We 
have a few frontends for it already. Company can use it, for one.

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

Hence we're bundling Company.