From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sat, 10 Oct 2015 11:00:46 +0200 Message-ID: <87pp0ngksh.fsf@fencepost.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444467854 26847 80.91.229.3 (10 Oct 2015 09:04:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 09:04:14 +0000 (UTC) Cc: Tom , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 11:04:14 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 1Zkq4Z-0006xB-7L for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 11:04:11 +0200 Original-Received: from localhost ([::1]:44130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkq4Y-0007rU-RF for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 05:04:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkq3i-0006WJ-1K for emacs-devel@gnu.org; Sat, 10 Oct 2015 05:03:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkq3g-0000gV-Tp for emacs-devel@gnu.org; Sat, 10 Oct 2015 05:03:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkq3f-0000fg-6p; Sat, 10 Oct 2015 05:03:15 -0400 Original-Received: from localhost ([127.0.0.1]:59551 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zkq3b-0004eK-LX; Sat, 10 Oct 2015 05:03:13 -0400 Original-Received: by lola (Postfix, from userid 1000) id 006BDE0F19; Sat, 10 Oct 2015 11:00:46 +0200 (CEST) In-Reply-To: <83bnc7tavr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Oct 2015 10:56:24 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:191102 Archived-At: Eli Zaretskii writes: >> From: Tom >> Date: Sat, 10 Oct 2015 04:33:59 +0000 (UTC) >> >> > If it falls short compared with other IDEs, I think this would be a >> > great area for improvement of Emacs. >> >> The number one requirement by IDE users today is perfect code completion >> and powerful refactoring support for the language they develop in >> (Java, C++, etc.). >> >> Any IDE which wants to compete with the popular IDEs must have these, >> because users find these features much more helpful in development, >> than keyboard macro support and such. >> >> So if Emacs wants to compete with these tools then it has to have seamless, >> context aware code completion and refactoring support, and GNU tools >> has to provide Emacs the necessary information to implement these >> features. > > I agree. But to have that, the only way is to have motivated > volunteers step forward and work on these features. Otherwise we will > never have them. > > Right now, no one is working on that, though everyone is talking. the > same as with weather. Not quite. IIRC, company-mode integrated (integrates?) the parsing facilities of Clang with Emacs. This contribution was rejected (though I don't have an overview over the actual execution of the rejection) because of promoting non-GCC compilers. However, attempts of letting GCC similarly output AST data were rejected as making it too easy to support non-free applications (obviously, if Emacs can use GCC for purposes of syntax analysis from the command line, so can anybody else). Using the recently admitted GCC plugin interface (previously, plugins were rejected because they would make supporting non-free applications too easy) for outputting a full AST was rejected since it would... You get the drift. A number of would-be contributors, partly with solutions or the impetus and skills for creating them, finally went elsewhere in disgust rather than trying to figure out the maze of which interoperations between GNU applications were acceptable and which not. So "no one is working on that, though everyone is talking" is sort of an unfair characterization because it implies that no one was willing to put his money and time where his mouth is. The main problem here is that the default behavior of GNU code is to refrain from serious interoperability since the GPL (as well as pretty much anything relying on copyright alone) does not reach across interoperable interfaces, until such a time that a concrete, strategically important application requires such interoperability, and then ways are searched to restrict the interoperability to the particular combination/application. So people's hands are bound until a complete plan has been worked out and/or blessed by Richard and shouting "no one is working on that" is disingenuous. I don't think this kind of micromanagement of interoperation can scale. Lots of worthwhile things come into being by plugging together existing components in surprising ways and that is an essential component of academic work and also of software freedom. Copping out whenever it gets serious is not going to help free software. At the same time, the FSF does not turn on a dime. Which is one of its strengths. The future of Emacs is one of the things which has an impact, and so is the future of GCC. The GPLv3 is a large "poison pill" that actually uses copyright in order to disarm the use of patents as a weapon. In my opinion, we should rely on its leverage for keeping the worst of the proprietary misuses in check and give mostly free rein on interoperability with regard to technical measures. It's been good enough for making Apple go away and leave GCC alone for building its future developer prisons. For that reason I am glad that John has volunteered to take a look Emacs maintainership and that he brings the motivation and skills to work on Emacs being a good IDE and hopefully the motivation to work out with GCC and RMS about what would be required and how to get there. Because we've made use of the "it's all talk" excuse far too long for postponing tackling the increasing issue of interoperability as a design criterion for Free Software under the GNU umbrella of the FSF. It's not "all talk" with John on board and I'm glad that he is willing to talk his application through with Richard. I severely doubt that it will be the only time he'll need to talk over things with Richard. And they are coming at Emacs from different sides and views that will never be the same and don't need to be. But the current incompatibility seems gratuitously bad to me and I think progress on that is quite necessary. -- David Kastrup