Re: IDE

[Dmitry Gutov]

On 10/18/2015 12:08 PM, Przemysław Wojnowski wrote:

> > The meanings of "go to definition", "find references" and "complete
> > text at
> > point" are very much the same across languages.
> Yes, and EDE could be changed to provide such API.

You probably mean Semantic.

> > Some refactorings, too.
> And some are not and will never be, because languages are too different. So
> IDE's support for them will be different or crippled to the lowest
> denominator as you seem to suggest.

You're just arguing for the sake of arguing here. We could have a common 
UI for implementing refactoring commands, and some of those commands 
could be different for different languages. Or something along these lines.

> > A more idiomatic, Emacs-y
> What does that mean? Is it described somewhere what is idiomatic in
> Emacs Lisp?

In the manual, maybe. I wouldn't know.

Point is, we can have a better, friendlier and more general API. And 
when we know that it makes sense, we can also change the existing code 
to fit it.

> I don't waste resources on duplicated efforts just to show my ego. Have
> many other things to work on.

Working on EDE can be more than an ego trip: maybe you'll stumble on a 
good, practical flexible design (which isn't out of the question, given 
a lot of code you'd have to keep working). And if EDE is more flexible, 
most likely we could reuse pieces of it more easily as well.

Did you actually intend to do some work on project support, or was that 
just backseat driving?

> > We can reuse code from EDE, if it fits.
> Depending on what you means by "it fits", but if that's possible, it's
> ok for me.

Build tool support code should fit the bill when project.el supports 
build tools (or maybe we'll separate that into build-tool.el).

> My only concern is that EDE is something that already works, but needs
> improvement. Creating, more or less, the same from scratch is IMHO
> reinventing the wheel, which may not even end being as round as EDE is.

Projectile already works, too. And eproject. And ENSIME, and Eclim. The 
two last examples also use their own code to manage projects, and I 
suspect it would be easier to ask them to implement a bridge to 
project.el, rather than migrate to EDE.

> Also reusing EDE maybe would "reuse" developers that were/are working on
> it and

Nope. David and Eric are pretty busy, and won't magically become active 
Emacs contributors just because of that.

> hence Emacs would have another contributors for free. Not doing so may mean
> that some devs will work on EDE and some on project.el, duplicating many
> things
> and loosing steam by lone work.

project.el is foremost an API, so it needs better design proposals, 
rather than more teamwork, right now. Improving EDE design would also 
help there.

> the same, but unusable for users - the most common scenario in open source
> world (see JDEE, malabar-mode, eclim).

I wish wish we could say that each of those projects has got *something* 
working really well, so it would make sense to talk about combining them.