From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Tue, 06 Oct 2015 16:53:40 -0500 Message-ID: <87a8rvu0ij.fsf@red-bean.com> References: <874miapdhs.fsf@openmailbox.org> <8737xuuw2y.fsf@rabkins.net> <87lhbmkrle.fsf@fencepost.gnu.org> <87si5r22qh.fsf@fencepost.gnu.org> <5612CEA6.3010809@yandex.ru> <87egh95cze.fsf@gmail.com> <5612D36B.1030906@yandex.ru> <87a8rx5awg.fsf@gmail.com> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444168431 28036 80.91.229.3 (6 Oct 2015 21:53:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 21:53:51 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 06 23:53: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 1ZjaBA-0003sy-CU for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 23:53:48 +0200 Original-Received: from localhost ([::1]:54232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaB9-0007zu-Tk for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 17:53:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaB7-0007zn-3P for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:53:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjaB4-0002jt-82 for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:53:45 -0400 Original-Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]:34875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaB4-0002jV-2s for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:53:42 -0400 Original-Received: by ioiz6 with SMTP id z6so2125963ioi.2 for ; Tue, 06 Oct 2015 14:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=OgH050W/42Q7dHfKfibptXLavubcX4uIJ3UyDzQroP0=; b=kfxwjMHdgIW7XaupF8wzUfoBbFG8YBD+Yl/GRZS4uazodXaKXwx1Un9CZcuKXtfTHN FGGya3ikV9qe6qgtgkD9+ZFiFunSo/zPgCJhqBDJtWzCsjMDkmJolB3j1k7IZmZMWbfZ +gIUantSz0UydOWWLyYwhd3D0DBJnwqRdQ5UDC3z1gNbLXl7ZmP3KRC11jxgrA/wKY/x aDyeQWslKh+mRhir4zdXXSuE0x+9e5j2IAKQMnUw7876ChdoZ3Zo52o81fFXVnjDRYxu H/ELvdkZGDLma9bLjtPVt2ZXj9X+jNHXRsG7wlF0Fs0bO5oTFzWuUt48OUMkZ2n2itdo 2vaA== X-Received: by 10.107.9.212 with SMTP id 81mr35814187ioj.191.1444168421510; Tue, 06 Oct 2015 14:53:41 -0700 (PDT) Original-Received: from floss (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id q10sm7598384igh.4.2015.10.06.14.53.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2015 14:53:40 -0700 (PDT) In-Reply-To: (John Wiegley's message of "Mon, 05 Oct 2015 13:37:34 -0700") 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: 2607:f8b0:4001:c06::22a 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:191024 Archived-At: "John Wiegley" writes: >I interpret him as meaning that the support should not favor non-GCC compilers >in any way, not that GCC should determine the least upper bound on >functionality. Just to confirm what others have pointed out: Given the context and past discussions, I think you would better assume that Richard meant "If GCC doesn't *actually* support the feature, then Emacs shouldn't add support for that feature just because Clang does." I think at the very least the criterion would be that an actual patch to GCC must exist, even if no release of GCC includes it yet. That's just a guess though. It's an open question whether the requirement would be that the FSF version (i.e., what we would call the "official" version) of GCC must support the feature, or whether it would be sufficient for the feature to be supported in a publicly available patch to GCC. I hope the latter, since that's exactly the point at which Emacs's corresponding support would no longer be merely "theoretical" with respect to GCC. > Isn't crippling the output of GCC, to prevent use by proprietary > vendors, a direct example of limiting *our* freedom, as users who want > access to that information to improve our use of Emacs (or other > tools)? Making such information available does not make GCC or Emacs > in any way more proprietary or freedom-destroying. If anything, it is > liberating the information known to these applications, so that it can > be more widely applied. What one group chooses to do to their copy of a free software program can *never* interfere with others' freedom w.r.t. that program, because those others are always free to do whatever they want with their own copy. If the FSF chooses not to add a feature to GCC, that doesn't interfere with your freedom. It may interfere with your convenience, but respecting people's freedom does not require supplying them exactly the thing they want, it merely requires not interfering with their ability to procure what they want by whatever means are available to them. The FSF can't "cripple" GCC. It can only cripple *its version* of GCC. You and anyone else are free to make a non-crippled version of GCC, and that's what freedom means :-). Best, -Karl