From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Mon, 12 Oct 2015 23:54:31 +0200 Message-ID: <561C2C17.3090503@cumego.com> References: <5610207A.2000300@harpegolden.net> <83fv1r3gzp.fsf@gnu.org> <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444686899 22363 80.91.229.3 (12 Oct 2015 21:54:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 21:54:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 23:54:50 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zll3Q-0006aa-9B for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 23:54:48 +0200 Original-Received: from localhost ([::1]:58984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zll3P-0006rf-MM for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 17:54:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zll3L-0006rM-77 for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:54:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zll3H-0001aC-Q6 for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:54:43 -0400 Original-Received: from smtp23.iq.pl ([86.111.242.228]:52904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zll3H-0001Wf-B3 for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:54:39 -0400 Original-Received: (qmail 31917 invoked from network); 12 Oct 2015 21:54:32 -0000 Original-Received: from unknown (HELO [192.168.1.102]) (esperanto@cumego.com@[159.205.196.239]) (envelope-sender ) by smtp22.iq.pl with AES128-SHA encrypted SMTP for ; 12 Oct 2015 21:54:32 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <561B9D87.70504@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 86.111.242.228 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191407 Archived-At: 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.