From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 10 Oct 2015 12:40:25 +0300 Message-ID: <831td3t62e.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1444470044 25106 80.91.229.3 (10 Oct 2015 09:40:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 09:40:44 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 11:40:35 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 1Zkqdl-00070i-AY for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 11:40:33 +0200 Original-Received: from localhost ([::1]:44228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkqdk-0004KZ-Al for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 05:40:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkqdd-0004KR-Pd for emacs-devel@gnu.org; Sat, 10 Oct 2015 05:40:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkqda-0006Wo-CW for emacs-devel@gnu.org; Sat, 10 Oct 2015 05:40:25 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:40784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkqdZ-0006Wi-U3 for emacs-devel@gnu.org; Sat, 10 Oct 2015 05:40:22 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NW000L0002B3500@mtaout29.012.net.il> for emacs-devel@gnu.org; Sat, 10 Oct 2015 12:41:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW000EU208YEC70@mtaout29.012.net.il>; Sat, 10 Oct 2015 12:41:22 +0300 (IDT) In-reply-to: <5618D376.1080700@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:191104 Archived-At: > Cc: adatgyujto@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 10 Oct 2015 11:59:34 +0300 > > On 10/10/2015 11:30 AM, Eli Zaretskii wrote: > > > I was talking about working on IDE, not on completion. And for the > > most popular languages in the industry, not just for some a few niche > > languages. > > You quoted the message that said "accurate code completion and powerful > refactoring support". No, I responded to a response. The origin was this: > If it falls short compared with other IDEs, I think this would be a > great area for improvement of Emacs. IOW, the issue is making Emacs a good IDE in general, including features for browsing code, refactoring, debugging, and all the other features users expect from a modern IDE. Come to think of that, even coming up with a list of such features would be real progress, as I don't think we have that, or ever had. > I can agree that the latter is barely touched (*), > but it looked like you ignored the former. I didn't ignore that. I just don't see an effort to make Emacs a modern IDE. Working on separate parts of that in separate uncoordinated activities is not the way we should pursue this, IMO. It's inefficient at best, and at worst will end up with those uncoordinated parts falling into oblivion when their driving forces move on. > > Let's not reiterate past discussions: you forget CEDET. > > I was enumerating external programs. But sure, CEDET is a yet another > option for completion. Though not too "accurate" one, if we're talking > anything but C. It needs to be actively developed. Much more actively than it is now. > > And if anyone _really_ cares about supporting C/C++, they should be > > working with and on GCC's libcc1, which is available for quite some > > time already. > > I wasn't aware of it. Is its API stable? I don't know. It's for someone who will work on this to find out. I know that a motivated individual in the GDB development team already based a useful set of commands on it -- you can compile and inject code into your program while debugging it. > Is it a good-enough replacement for libclang for the purposes of > completion? I don't know. If it isn't, then the team who will work on the Emacs IDE will have to take care of extending libcc1 as well, or find someone with the GCC team to do that. Exactly like that GDB developer did when he needed features that were missing: he implemented them himself, with guidance from GCC developers. > > I expect to see a coherent, orchestrated effort towards having an IDE > > mode in Emacs. I don't see it, certainly not in discussions on this > > list. I also don't see any commits that would provide evidence of > > such an effort. > > We definitely could have more in this department, yes. But what would > you even call an "IDE mode"? A fixed multi-window setup a la ECB? I don't know, and neither do we as a project. A useful step would be to produce a detailed answer to that question. That answer could both serve as base for useful discussions, and might provide some anchor for all those external packages you mentioned to target some coherent vision. > I prefer to approach this problem from the bottom - like adding new > commands that perform certain advanced functions. I don't believe comprehensive features such as IDE can be developed exclusively bottom up. There should be some basic set of assumptions and design rules/decisions that everyone should target and abide by. There should also be some unified leadership. > > If such activities happen somewhere else, I would suggest their > > participants to come here and work with and within the core. > > That's... unlikely. At least, for most of them. My guess is that the > mailing list interface is off-putting, but maybe we just need a better > "community outreach" program, or something like that. When the work begins in earnest, discussions are rarely needed, except for discussing some very important design decisions. Most of the time you just develop your corner. Lots of discussions about some feature is IME the first sign that no one is actually working on it in any serious way. I remember the beginning of the bidi development: it started by a few years of discussions (on a separate mailing list) that led nowhere, and most of them didn't even contribute any useful ideas for what eventually became the implementation we now have in Emacs. Once I started to actually work on this, there was a small number of threads (maybe 5) here, when I felt I needed to share my main design decisions and get some feedback. > That would be something for the new maintainer(s) to consider. Indeed. > > For > > starters, I don't imagine they would succeed without some significant > > changes and additions in the core infrastructure. The place to > > discuss that is here. > > For refactoring, yes. But just "accurate code completion", without > extras like expanding the arguments or displaying the method source, can > be (and is, in certain packages) implemented though the > completion-at-point-function interface, present in Emacs since 24.1. We didn't even decide that we want that as our mechanism. Did anyone consider how this compares with what the other modern IDEs offer? What if we build our completion on a UI that today's developers will dislike? Unlike with many traditional Emacs features, which were developed when there was no prior art, the IDE features have lots of prior art. No need to invent the wheel, just implement similar look and feel. > > Then what exactly is the nature of your objections to my observations? > > It seems we agree on the bottom line: no one works on this. The > > reasons are immaterial. > > If anything, my view of the situation is a lot brighter than yours. I'll be happy to stand corrected. Unfortunately, I don't yet see any significant changes in the right direction, so my pessimism is for now at least as justified as your optimism.