Re: IDE

[Dmitry Gutov]

On 10/11/2015 04:18 PM, Przemysław Wojnowski wrote:

> For (project-oriented/enterprise) Java the features are:
> 1. Project support
> IDE has to know the boundaries of a project - where are sources, tests,
> libs, resources/assets (additional files used in an app in runtime),
> docs - and what are relations between them. Also it has to know how to
> work with project's build tool (be it Maven, Gradle, etc.).
> A programmer joining a project (99% of cases) should be able to
> open/import it and start work. Every Java IDE have that.

Emacs master now has project.el, which will be a step in this direction.

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.

So I'm not sure how to solve this. Have a "jump-to-related-file" 
command, which will prompt for the type of the resource when invoked?

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.

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

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

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

> 5. Automatic compilation and showing compilation erros/warnings.
> Tightens development feedback loop.

Flycheck. Sadly, it's not in Emacs.

> 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, and/or an 
ability to interact with a debugger/REPL if it's triggered during the 
test run.

> One variation of Extract Method is "EM with finding duplicates", which
> works like this:
> - ask user for a method name,
> - find all occurrences of selected code in the buffer
> - ask user if she wants to replace all occurrences with the call to the
> new method.
> This is fantastic feature that Intellij has and helps to remove a lot of
> duplicated code.

That sounds useful indeed.