Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/13/2015 12:54 AM, Przemysław Wojnowski wrote:

>> Emacs master now has project.el, which will be a step in this
>> direction.
> I have seen that thread, but unfortunately haven't read it, yet.
> It's waiting for the nearest holiday. :-|

There have been several threads about it.

> IMHO defining relations between project elements should be delegated
> to each type of project. For example Java Project knows where are
> sources/tests/resources and can setup that using Project API.

Yes. So, what would do we do about the set of available commands?

> Moreover in one project (lets call it Meta Project) there
> should be a way to configure a set of language specific
> subprojects, each one having its own backend(s) setup
> (for code completion, docs, etc.).
> A backend would be chosen by a mode in the current buffer (region?).

I'm not sure about all that, but code completion and docs are outside of 
project.el's jurisdiction anyway.

> IMHO better approach would be to provide an API that could be
> used by build tool specific plugins to add build tasks
> (in a Command Pattern manner). Such registered commands could be
> presented to a user in some uniform form. For example:
> In Maven plugin:
> (build-api-add-command
>    {name: "compile", command: function-ref})

Mmm, yes. Allowing some code outside of the project definition to define 
the tasks and the way to run them might be better.

On the other hand, often the project definition file and the build file 
would be the same. So the project backend would have to read it anyway.

> Of course, there can be more than one build tool in a project,
> so, if windows/menus were presented, the user would see for each of them
> or maybe depending on current buffer's mode.

A build file (or several) is usually related to the project as a whole, 
so picking based on the current file might be suboptimal. On the other 
hand, we could present tasks from all build files combined.

> But the point is to provide an API not an implementation.

Sure. Please feel free to have a stab at defining it.

> IMHO, as many other things, this should be delegated to external tools
> that specializes in that. And CEDET should allow to use a set of
> external backends (at the same time).

Proposals which external tools exactly the Emacs core can use, will be 
welcome.

> How to teach a backend (xref, CEDET, etc.) what my project is?

An xref backend can call (project-current). But something (probably a 
minor mode) would have to set the appropriate xref backend.

> IMHO even good TAGS backend would be a good start if I, as an Emacs
> user, wouldn't need to configure it for a week and fight with each
> package to use it. This is where IDE steps in - it integrates.

The etags backend is currently the default one.

> Depending on language environment there may be different options. In
> Java world most build tools have plugins to run tests (single, group,
> all, etc.). So, Emacs Unified Test Runner could delegate that task to
> the tool and display the result (clearly the result can be displayed in
> many ways - other window being the simplest one, but the problem has
> been solved by MVX patterns decades ago).

Of course it would have to call the tool. That doesn't solve the 
questions of error highlighting and debugger integration.

> Again, the test runner could provide an API for project types to
> register language specific runner Commands - this way a Java file may
> have, for example, two runners BuildToolRunner (that calls build tool
> command) and DirectJavaRunner (that instantiates and runs the test
> directly).

I'd like to look at specific proposals for how this would look inside 
project.el, or some other, new file.

> To clarify, I've just listed features that I know are expected from a
> Java IDE. Some of them have implementations in Emacs/packages or
> external tools used by them. The point is that an IDE should _integrate_
> that tools/packages, not end users.

Sure, that would be better.

> At this moment whenever Emacs user tries to use a language she has to
> find a blog post that describes how to configure Emacs to be able to do
> something.

That might still be the case afterwards, to some extent, but at least 
after she's configured Emacs, the experience will be more consistent, 
and similar between different languages.