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: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 19:55:02 +0100 Message-ID: <87vbw36n09.fsf@fencepost.gnu.org> References: <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87mwhjdq32.fsf@fencepost.gnu.org> <87r46s9y6m.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393361342 3013 80.91.229.3 (25 Feb 2014 20:49:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 20:49:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 21:49:09 2014 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 1WIOw9-00064s-25 for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 21:49:09 +0100 Original-Received: from localhost ([::1]:36987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIOw8-0000Ic-Mu for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 15:49:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIOw4-0000G8-Dx for emacs-devel@gnu.org; Tue, 25 Feb 2014 15:49:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIOw3-00086K-5C for emacs-devel@gnu.org; Tue, 25 Feb 2014 15:49:04 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIOw3-00086D-1T for emacs-devel@gnu.org; Tue, 25 Feb 2014 15:49:03 -0500 Original-Received: from localhost ([127.0.0.1]:33516 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIOvw-000422-35; Tue, 25 Feb 2014 15:48:56 -0500 Original-Received: by lola (Postfix, from userid 1000) id 732C6E04EC; Tue, 25 Feb 2014 19:55:02 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Tue, 25 Feb 2014 12:15:01 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.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:169871 Archived-At: Richard Stallman writes: > > Actually yes they were (though not with those words). Someone > > cited my decision against having GCC write a complete syntax > > tree. That output would make it easy to use GCC as a front end > > for nonfree back-ends. That would be tantamount to making > > nonfree versions of GCC. > > I disagree. > > Disagree if you like, but I think it is true in this case. Well, I think "complete syntax tree" is probably mostly a red herring not worth the fight we have been seeing over it. It is most likely rather version- and language-specific and likely quite bound into GCC's internals whenever one wants to be serious about "complete". It would appear (from a separate reply) that the information written by -fdump-xref is basically the info that any completion server/daemon would have to provide access to (if one does not just parse it in Elisp itself), and that in the context of the Ada backend there has already been written a tool that reads it and provides the respective information for Ada, C, and C++. So it would appear that these eggs have not just been laid but already hatched and most of the emotions invested into this discussion are moot anyway. > * When I say "nonfree versions of GCC", what I mean is the use of > parts of GCC as part of a nonfree compiler. There are various ways > that could be implemented, but the harm is the same. Well, GCC consists of multiple executables implementing multiple passes. One could always replace the second executable, but I suppose that this would be enough of a mess that calling the combination a "mere aggregation" would, in spite of separate address spaces, be ridiculous enough that nobody would consider that a valid defense. I think similar restraint would apply for most operations resulting in an actual full compiler. Things are different with plugging GCC into a fully proprietary IDE. I don't really see that any interfaces we concoct in order to use GCC as a more-than-just compiler component of an Emacs-based workflow could be kept from getting used for integrating GCC for the same purpose into a proprietary IDE without causing a combined work to be covered by the "software as a whole rather than mere aggregation" clause. So I'm not sure that much to really fight over remains once we are delving into concrete applications we want to implement based on GCC in an environment such as Emacs. Either everybody gets it or nobody. What _is_ satisfying, however, is that once big companies with a patent portfolio use and distribute GCC for getting more value out of proprietary offerings from them, we more or less get patent indemnification for doing the same feature inside of Emacs as an IDE: that's a nice benefit of GPLv3. Which makes me suspect that we won't see large-scale misuse of GCC. None of the big players want to risk effectively foregoing any of their patents all of which, no matter how ridiculous, are potentially worth millions or even billions of dollars. GPLv3 was accompanied by enough of a predictable backlash that it seems wasteful not to amend our strategies where we consciously paid the price for changing the battlefield to our advantage. We lost ground with LLVM, and we gained ground with GPLv3. We should take both into account. -- David Kastrup