Re: [PATCH] Flymake support for C/C++

[Reuben Thomas]

On 25 October 2017 at 20:30, Richard Stallman <address@hidden> 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.