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: New maintainer Date: Wed, 07 Oct 2015 00:15:10 +0200 Message-ID: <87h9m38x01.fsf@fencepost.gnu.org> 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> <87a8rvu0ij.fsf@red-bean.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444169776 15720 80.91.229.3 (6 Oct 2015 22:16:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 22:16:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 07 00:16:15 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 1ZjaWt-0000xl-5q for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 00:16:15 +0200 Original-Received: from localhost ([::1]:54346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaWs-0008M7-6v for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 18:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaVt-0007aC-30 for emacs-devel@gnu.org; Tue, 06 Oct 2015 18:15:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjaVr-0007tn-Ul for emacs-devel@gnu.org; Tue, 06 Oct 2015 18:15:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaVr-0007tj-Su; Tue, 06 Oct 2015 18:15:11 -0400 Original-Received: from localhost ([127.0.0.1]:36146 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZjaVq-0003E8-Rh; Tue, 06 Oct 2015 18:15:11 -0400 Original-Received: by lola (Postfix, from userid 1000) id 375A9DF4EF; Wed, 7 Oct 2015 00:15:10 +0200 (CEST) In-Reply-To: <87a8rvu0ij.fsf@red-bean.com> (Karl Fogel's message of "Tue, 06 Oct 2015 16:53:40 -0500") 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:191027 Archived-At: Karl Fogel writes: > "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. I should think that the requirement would be that the patch would be acceptable into the FSF version. Reasons for non-acceptance would be a lack of copyright assignment, or a mismatch with FSF policies. It's really not speculative how this pans out: just look up the recent GCC/AST/Smartcompletion spat on the Emacs developer list. -- David Kastrup