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: Tue, 06 Oct 2015 09:31:41 +0200 Message-ID: <87egh8a1wi.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444116746 12441 80.91.229.3 (6 Oct 2015 07:32:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 07:32:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 06 09:32:25 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 1ZjMjY-0004p9-0U for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 09:32:24 +0200 Original-Received: from localhost ([::1]:49360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjMjW-0005ss-3u for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 03:32:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjMiu-0005Iv-Ae for emacs-devel@gnu.org; Tue, 06 Oct 2015 03:31:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjMis-0001FO-PV for emacs-devel@gnu.org; Tue, 06 Oct 2015 03:31:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjMis-0001FK-NS for emacs-devel@gnu.org; Tue, 06 Oct 2015 03:31:42 -0400 Original-Received: from localhost ([127.0.0.1]:48100 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZjMis-00081l-5j for emacs-devel@gnu.org; Tue, 06 Oct 2015 03:31:42 -0400 Original-Received: by lola (Postfix, from userid 1000) id 8698EDF4A3; Tue, 6 Oct 2015 09:31:41 +0200 (CEST) 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: 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:191002 Archived-At: "John Wiegley" writes: >>>>>> Jay Belanger writes: > >>>> Maybe I'm misreading it, but it doesn't sound like what Richard meant at >>>> all. I read it as the features have to actually work with GCC ("not just a >>>> theoretical idea") to be included. >>> >>> The issue is that GCC, in its current state, doesn't provide a certain >>> set a features Emacs can take advantage of, that Clang does. > >> That's the point. It sounded like Richard was saying that in that case, >> Emacs shouldn't take advantage of it. How else could > >>> If it really works usefully with GCC -- if that is not just a theoretical >>> idea -- then I won't object to its supporting other compilers as well. > >> be interpreted? > > 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. That interpretation is not supported by the mailing list history. In particular, there were (and still are) conscious restrictions to the amount of information GCC may provide in a generic format and/or via a generic plugin interface since such generic mechanisms define the "application as a whole" border beyond which copyright and consequently the GPL does not reach. If Emacs now provided functionality using Clang that has been intentionally omitted from or restricted in GCC, this would be self-defeating. So yes, in that respect GCC _does_ determine the least upper bound of functionality. This has by far been the most heatedly debated influence of GPL-supporting strategic decisions on this mailing list in the last years and has even be covered in "Linux Weekly News" several times (searching for "Emacs" in their archives will likely pull up references). The way to make progress in such areas may thus be the most frustrating part of Emacs maintainership as it requires pushing for changes with GCC in lockstep, and in this case not just functional changes (which already provide a challenge and thus can be expected to move forward rather slower than faster) but also strategic direction changes. If you want to go there, it might be an idea starting with the Ada-specific GCC fork which probably went under the radar with its option exporting the parse tree. Working on a good proof-of-concept using that is probably the most convincing argument you can make. The good news is likely that this is about the most you can expect in the area of influence of the GPL and associated policies on Emacs, so if you make yourself acquainted with the happenings there, you have seen the practical side of the limitations due to licensing. -- David Kastrup