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: Contributing LLVM.org patches to gud.el Date: Fri, 06 Feb 2015 20:21:25 +0100 Message-ID: <877fvuyhfu.fsf@fencepost.gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423250513 9738 80.91.229.3 (6 Feb 2015 19:21:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2015 19:21:53 +0000 (UTC) Cc: slewsys@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 06 20:21:52 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 1YJoTO-0005kV-Mj for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 20:21:50 +0100 Original-Received: from localhost ([::1]:50237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJoTO-0001jm-2W for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 14:21:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJoT8-0001iw-Pa for emacs-devel@gnu.org; Fri, 06 Feb 2015 14:21:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJoT7-000502-Fn for emacs-devel@gnu.org; Fri, 06 Feb 2015 14:21:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJoT7-0004zx-CH for emacs-devel@gnu.org; Fri, 06 Feb 2015 14:21:33 -0500 Original-Received: from localhost ([127.0.0.1]:60389 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJoT0-0001pm-86; Fri, 06 Feb 2015 14:21:26 -0500 Original-Received: by lola (Postfix, from userid 1000) id CF772E068B; Fri, 6 Feb 2015 20:21:25 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Fri, 06 Feb 2015 13:21:08 -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:182556 Archived-At: Richard Stallman writes: > [[[ 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 cannot see how it differs from us supporting MS Windows and MacOSX in > > Emacs. The metric we employed here was not to install support for any > > functionality restricted to the use of those operating systems. > > These are not similar cases. Neither Windows nor MacOS was intended > to push major GNU packages out of use. Basing MacOS9 (?) off a Mach/BSD kernel could have been that but what started out as a semi-open strategy for Darwin was eventually suffocated by the Apple culture with its preference of locking things down and keeping them secret. Still it was much more going into the "push out of use" direction than this here is. Microsoft also had a serious push against free operating systems with its SFU (Services for Unix, Interix), a seriously outdated GNU userland interacting closer with the Windows NT kernel than either Cygwin or Mingw32. > What I see here appears possibly to be exactly that. Whether that is > the case is what I want to find out. I don't see that, but of course you'll be doing your own assessment. However, this _is_ actually related to the recent LLVM/GCC/AST discussions we had here in that it again concerns throwing a spanner into interoperability. Emacs _is_ glue for tieing applications together into one editing surface. And gud.el is designed for interoperability and tieing into a variety of different debuggers. This has been one of its design goals for decades, and it does support various other debuggers different from gdb, including proprietary ones (at least the SVR4+ family of debuggers was proprietary for a long time, and in spite of the existence of OpenSolaris, most variants of them probably still are). Supporting another debugger is what gud.el has been _designed_ to support, and Emacs has been designed to interact with lots of applications. That's one of its principal strengths. Trying to mess with that takes away one of the fundamental attractions of Emacs, namely being universally useful. This universal usefulness has a lot of aspects: large platform support (also helped by GCC targets and autoconf), lots of ports, generic interfaces and so on. It has been one of the historic pillarstones of the GNU projects: one of the fundamental attractions of the GNU userland was that you could get it to run on more platforms than many other solutions, to the degree where your chances to compile something under/with both Cygwin and GNU/Linux was better than under/with both Solaris and Xenix (for example). What recent decisions and decision finding processes lead to amounts to throwing away the GNU system's capability of serving as a skeleton key, a solution one uses because it will work better across different tasks, platforms and philosophies than its competition because many people have been able to work on it according to their own interests. The freedom of choosing what you want your free tools to work with may not have been philosophically anchored in the GNU project's principles, but it has been one driving aspect of freedom that has made people appreciate the freedom of being able to take their tools wherever they go. For many, it is one of the things they have become passionate about, and it was an essential part of what GNU meant particularly when we had no free kernel to rely on. Excising the general usefulness of GNU _now_, and that is the trend which recent attempts of decision-finding (whether or not they can be considered finished) were focused with, is something that will come at a cost that I don't see the GNU project able to carry. In my opinion, it would cut too close to the heart of the project and its history. In the light of that, it is sad that we don't appear to have workable strategies in place for making decisions about interoperability. Any such case where the decision-finding is opaque to people interested to working on parts of GNU, and where it drags on for an indeterminate amount of time, is putting enthusiasm terminally to rest that would have better spent on improving GNU. We cannot afford to continue without a predictable strategy towards interoperability and easy, reliable and speedy decision-finding processes based on such a strategy. This is particularly important for as widely useful and portable applications like Emacs and GCC. -- David Kastrup