Re: IDE

[Przemysław Wojnowski]

W dniu 2015-10-12 13:46, Dmitry Gutov napisał(a):
> > For (project-oriented/enterprise) Java the features are:
> > 1. Project support
[...]
> 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. :-|

> We can extend that API to contain information about where certain
> resources are, but for each type of projects there will be a different
> set of resources. While we could have a jump-to-test command (tests
> should be common), we can't easily have a commands for each kind of
> "jump to the web template for this controller" action.
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.

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

For example in a common "Java" webapp, the Meta Project setup could be:
{ languages:
  { java: {backend: classpath-indexer, build-tool: gradle, 
other-options: ...}
    javascript: {backend: tags-backend, build-tool: npm, ...}
    groovy: ...} }

> Support for build tools seems more straightforward, someone should
> just collect an overview of how users interact with different ones,
> like Make, Maven, Gradle, Rake, etc, to firmly establish the common
> ground.
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})

When user selects a command the unified build tools runner does:
(defun build-api-run (command)
  (apply command.function-ref))

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.
But the point is to provide an API not an implementation.

> > 2. Code completion
> >  From whole project, used libraries, and resources
>
> Unless CEDET delivers on that front, we're unlikely to have completion
> for Java in the near future in the core. But there are third-party
> packages that provide 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).

One thing I'm not sure is whether CEDET should be used. IMHO yes, but 
AFAIR I've seen different voices on the list. So, not sure about that.

> > 3. Jumping around the project code and resources.
> > Jumping to around the project code and used libraries. Another thing
> > is
> > jumping to/from resources (for example aspects can be defined in an
> > XML file and IDE could allow to jump to matching classes).
>
> Do you mean "jump to the thing at point"? That sounds complicated, and
> support for different "things" will have to be implemented separately.
Yes, it would need to be implemented separately by each project type, 
because only project types know how to add semantic to different resources.
For example a Java project seeing Spring in dependencies may assume (or 
ask user) that applicationContext.xml file in actually Spring 
Application context, hence would know which elements are class names and 
then could use Java backend from the same project to find class' source.

> > 4. Finding usages of fields, methods, types.
> > Helps to wrap head around project.
>
> That's within the purview of xref, and up to CEDET or external tools
> to implement. But you can try xref-find-references now, for a
> quick-and-dirty Grep-based solution.
How to teach a backend (xref, CEDET, etc.) what my project is?
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.

> > 6. Running the tests (current, selected, all)
> > Tighten development feedback loop.
>
> Not sure which facility would be most fitting. A project *could*
> include metadata about how to run its tests better, but then the
> resulting buffer would need new compilation-error-regexp-alist
> entries,
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).
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).

In the places where an API would be exposed I would see an EIEIO 
interface to make it explicit.

> [...] and/or an ability to interact with a debugger/REPL if it's
> triggered during the test run.
I have to think about that.


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

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.