From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Flymake support for C/C++ Date: Fri, 27 Oct 2017 01:43:28 +0100 Message-ID: References: <87zi8wmmhw.fsf@gmail.com> <83tvz2i2fv.fsf@gnu.org> <83r2u6i0ws.fsf@gnu.org> <87fuaivyeg.fsf@russet.org.uk> Reply-To: rrt@sc3d.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1509065035 3775 195.159.176.226 (27 Oct 2017 00:43:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 27 Oct 2017 00:43:55 +0000 (UTC) Cc: Noam Postavsky , Sami Kerola , emacs-devel@gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Alan Mackenzie , Eli Zaretskii , Leo Liu , Stefan Monnier , Phillip Lord To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 27 02:43:48 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7skG-000739-Us for ged-emacs-devel@m.gmane.org; Fri, 27 Oct 2017 02:43:33 +0200 Original-Received: from localhost ([::1]:55252 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7skO-0005xU-33 for ged-emacs-devel@m.gmane.org; Thu, 26 Oct 2017 20:43:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7skF-0005xL-Qf for emacs-devel@gnu.org; Thu, 26 Oct 2017 20:43:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7skE-0002Ow-LE for emacs-devel@gnu.org; Thu, 26 Oct 2017 20:43:31 -0400 Original-Received: from mail-oi0-x231.google.com ([2607:f8b0:4003:c06::231]:50399) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e7skE-0002OE-Fv for emacs-devel@gnu.org; Thu, 26 Oct 2017 20:43:30 -0400 Original-Received: by mail-oi0-x231.google.com with SMTP id q4so8605869oic.7 for ; Thu, 26 Oct 2017 17:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWNSlStwCNu1V/OjKpdRVWjsxNsUvTEsMbqDANHtLJQ=; b=dkush9V1ShDly4hWXT47edeIBVZ7urF5nGyWEOXKFzuV6hYs6CzhZ0X6d1qpThLlcO ElhRNv/mhqFiTtYnccROstN9JhJK04rZ1Wy9+Py1ZYneUcbNShK5QoAYfzg/No1KeZlT a8wh3rx4A3C8otFtLpvQW6WbTxKnlehI+Ry8U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWNSlStwCNu1V/OjKpdRVWjsxNsUvTEsMbqDANHtLJQ=; b=rTctvN1vorkGxPcVDIwiaeHEASU+f2SrqW2KnAlf72xHnD9G4FZIwNPZ4FKh4kCbCR TYWY1KPxDIdPLVD0ntHoT9ZWnBhA9SHsEWWa+05vVIS73OJdHVQT4DDHlcKCp+M4AtEJ I69OHACGq+6f3MI/mAryrs6rKYk9zcepaZ00V+2fRiPuootuRmUKwOMAm4MDw5D56R0f sJ2H8jt64p0epsviWsXSdVb9QQDqgexvAZtHzyPOloUXDBxju+JH9mM2Q8OULqe1ibFg j9co+83dsnQuTWqFPNowX0gguvEVUwey8g3cVQ23yI0NlQSbsEdB5y8K9CXlkr8LclBu Vw6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=fWNSlStwCNu1V/OjKpdRVWjsxNsUvTEsMbqDANHtLJQ=; b=hx65idStdObyA53R86IJWab/UxwjWwGeiKb4kzdnulPW1iUlPOrnFZAHKvbdC8wY4o Je99MHIrDbl7vNGGv9uGYv5FtZXH/qFXyxfXzEGB0h5Itiz8WtEDhYEAcFeHbWj70eqY SLwlnjlfkiOEGS+D0F1RPdWRRzWcwGdUkm9P+kdHeuSd1g5Lh8KCgrEtHIB51PB3CUtB pOK+rc4cZSz2nB565WaV4gVDBwXNEQH/7skUmtvWfLaEPuL9BdMdKMf8P3UrEJHSAadO s2/pK43Ho8GsMt4et1JeISToIOccQrZYV4k79G425pzAgPD2oRRXVeW8DYmURqkiXgcB 2Bhw== X-Gm-Message-State: AMCzsaUtpkGB/vWYN7AzXWQn5iIwTjx15Gwn1mh2fjHMz1fGymVjbfhN LcQqK3QRleq+vtl3R5tZmgmsTqx5IphXKd/074t1Sg== X-Google-Smtp-Source: ABhQp+QSNJ6HG2cdYJhzm6hLRPOZGXE3eHxfqTRSDmPG8j4EGwo+rhTwV1MLP03kPsG9z0EP+v9eXG3PUgusOHd5gC4= X-Received: by 10.157.92.129 with SMTP id a1mr3696680oti.27.1509065008984; Thu, 26 Oct 2017 17:43:28 -0700 (PDT) Original-Received: by 10.157.82.100 with HTTP; Thu, 26 Oct 2017 17:43:28 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: -tCCO-FOZZuHHG9zffWYnWQAZSo X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:219792 Archived-At: On 25 October 2017 at 20:30, Richard Stallman wrote: > [[[ 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 was saying that, just as we do not insist that all our C dependencies be > > a) installed in Emacs's git repository and b) distributed as part of Emacs > > source releases, there is no reason in principle why we cannot have > > external Elisp dependencies, for example Org and CEDET. > > Dependencies of Emacs are lower-level programs that Emacs depends on. > They are not specifically for Emacs; other packages use them too. We > accept general-purpose lower-level dependencies, and we don't have any > reason to distribute them unless we have made a modified version. > (Which we prefer to avoid, except when really necessary.) > > Org and CEDET are not dependencies of Emacs. Rather, they build on > the core of Emacs. > > We don't want Emacs to become a mishmash of pieces we distribute and > maintain and pieces we don't distribute and don't maintain. Do you mean "distribute and don't maintain" rather than "don't distribute and don't maintain" (as that sounds like the various ELPAs)? > So we have two ways of dealing with code that > builds on the core of Emacs: > > * You distribute it, you're responsible for it, and we don't support > it, promote it, or worry specifically about it. > > * It's part of Emacs, we distribute it as such, and we can fix it when > need be. These are not mutually exclusive, as demonstrated by the various GNU/Linux distributions that offer some support for packages they do not maintain: for example, distribution-specific integration, and, often, bug fixes, either before they get upstream, or that for some reason are approved by the distribution but not by upstream. This is often found to be tenable. In the case of Emacs, there's increasingly a tension: on the one hand, Emacs is a platform. It has long been a platform for applications, though applications tended to rot over time as Emacs evolved (because it's never been as stable as, say, POSIX or X). Now, it's also a platform for what one might call "distributions", like Spacemacs, Aquamacs and ErgoEmacs. At the same time, it is, increasingly, its own distribution. That's great: there's more functionality built-in to GNU Emacs, and it's quite distinctive as a distribution (in particular, taking a more evolutionary and less revolutionary approach than the others I mentioned). Good in particular for long-term users who are basically happy with things. However, it creates a maintenance problem: platform changes must bring a large amount of application code with them. And, from looking at git history, patches are often applied to Emacs first, and must presumably then migrate upstream into their respective projects. In short, we have the tight coupling of a monolithic project, plus the disadvantages of a distribution. It would be good to have a smaller codebase for the Emacs platform, that does not have to be developed in sync with "distribution" releases. This would permit improvements to be made to the underlying system without the same level of heroics (and deep familiarity with a huge amount of code) that is currently required to keep all the application code working on top. This applies not just to Lisp code: at present, it's necessary to consider non-GNU platforms (in some places, even DOS, a proprietary platform that has been obsolete for a quarter of a century!). Again, it would be nice to be able to work more like an OpenSSH developer: in our case, that means: develop the core platform purely for GNU, and leave porting it to other platforms as a separate exercise. This also has the potential to benefit other parts of GNU: for example, rather than have Windows or macOS-specific functionality in Emacs, where it's a burden on Emacs maintainers and only benefits Emacs, push it out to gtk, where it benefits other applications and has many more developers with a stake in its maintenance. Emacs works on many systems, but in many cases that is achieved not by being portable, but by a large amount of system-specific code. Similarly, Emacs offers an increasingly-impressive array of "out of the box" functionality, but still with considerable duplication and dead wood. I do not slight the considerable efforts that have already been made to improve this at both the platform and application level, but a great deal more effort is needed to reduce the barriers to both participation in Emacs development, and to platform-level improvements.