Re: Contributing LLVM.org patches to gud.el

[David Kastrup]

Richard Stallman <address@hidden> 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