From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Mon, 10 Mar 2014 15:08:09 -0400 Message-ID: References: <20140217203145.71a849f7@forcix.jorgenschaefer.de> <837g8t8ouc.fsf@gnu.org> <20140219080524.25689b6b@forcix.jorgenschaefer.de> <83k3cr58o2.fsf@gnu.org> <530BAEE5.9040004@online.de> <87ppmatkpe.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgfsxsr.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgf37n4.fsf@fencepost.gnu.org> <87ha7gshu9.fsf@uwakimon.sk.tsukuba.ac.jp> <871tyko9l5.fsf@fencepost.gnu.org> <87eh2ks897.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvn0mk25.fsf@fencepost.gnu.org> <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> <877g8bmxal.fsf@fencepost.gnu.org> <877g8asfl0.fsf@uwakimon.sk.tsukuba.ac.jp> <8738iyjrl3.fsf@fencepost.gnu.org> <87mwh5ridq.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqg9hn10.fsf@fencepost.gnu.org> <878uspaku2.fsf@wanadoo.es> Reply-To: rms@gnu.org NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1394479261 17891 80.91.229.3 (10 Mar 2014 19:21:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 19:21:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Óscar Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 20:21: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 1WN5l6-0004sm-T6 for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 20:21:09 +0100 Original-Received: from localhost ([::1]:50866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN5l6-0000K5-DZ for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2014 15:21:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN5kL-00081m-7e for emacs-devel@gnu.org; Mon, 10 Mar 2014 15:20:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WN5kI-0006u1-Fl for emacs-devel@gnu.org; Mon, 10 Mar 2014 15:20:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN5kI-0006sv-Cx for emacs-devel@gnu.org; Mon, 10 Mar 2014 15:20:18 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WN5YX-0003hi-M8; Mon, 10 Mar 2014 15:08:09 -0400 In-reply-to: <878uspaku2.fsf@wanadoo.es> (message from Óscar Fuentes on Tue, 04 Mar 2014 19:18:45 +0100) 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:170257 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I am not going to change my decision because of minor bad consequences or apparent inconsistencies, because those are less important than the what the decision aims to achieve. Maybe it is possible to improve some details of the decision. If so, I don't reject that out of hand. However, I am going to think long and hard to make sure a proposed change does not reintroduce the problem I am trying to exclude. For instance, suppose a feature is implemented to use CEDET. If so, why would we want code to implement the same feature using Clang, even as an option? If no one would ever use that option, installing it is a waste of time and a confusion for the users; we are better off without it. However, if there is a reason people might see an advantage in using that option, evidently its use of Clang constitutes a real problem. Let's implement the change with CEDET, if that works well. If it can work better using a real compiler, let's use GCC, not Clang. unfair scenario for GCC because, contrary to Clang, it wasn't intended to provide those features, The only sort of "fairness to GCC" that matters is to promote its use now, so that it can promote copyleft on compilers now, so that it can discourage nonfree compilers now. and past attempts to steer its development towards those goals were rejected by the same person who now spurs them to match Clang's library-like features :-/ In the past, I made decisions so as to promote free compilers and prevent nonfree compilers from displacing them. I do that now, and will do so in the future. If the methods I use today differ from the methods I used in the past, that should not be shocking. The contrast between past and present policies, even if ironic, tragic, or whatever, is no argument for anything. Whenever two things differ, an incomplete or misleading description of them can make that difference look like a horrible "inconsistency" than absolutely must be corrected. One must learn to disregard that sort of argument when it pops up. I am not infallible, but that's no reason I should not do my best. I will continue to make decisions in accord with the goals of the GNU Project. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.