Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation

[Phillip Lord]

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. ]]]
>
>   > Yes, well, that's the question at hand. Currently, ELPA is a place to
>   > store packages that are not maintained in core. But it could also be
>   > used to enable a much smaller core, with many more packages in ELPA.
>
> I think of this as a matter of details, quantitative rather than
> qualitative.
>
>   > > I think that should be done by explicit command, not automatically or
>   > > spontaneously, and not as part of building Emacs.
>
>   > Indeed, that is the status quo. But it is problematic, because users
>   > have to know about the package in ELPA to install it in the first
>   > place.
>
> I think we are miscommunicating.  I'm talking about the procedure for
> building the core Emacs release.  That is what was brought up before.
>
> You seem to be talking now about how users use a given ELPA package.
> These are fundamentally separate issues.
>
> How to inform users about ELPA packages is also a separate issue.
>
>   > A smaller "core" would allow a more rapid release cycle. Many of the
>   > packages could be maintained independently; missing a release cycle
>   > would no longer mean users waiting a year or two for an update.
>
> Maybe you're right, but that's a different issue.  We can discuss that
> later -- for now, let's focus on the question of building the Emacs
> core.
>
>   > > I think you have changed the subject,
>   > > but since what you said is very general, I can't be sure.
>   > >
>   > > What sort of things do you mean?
>
>   > All the dev-tools -- compilers, headers, autoconf.
>
> To build a package requires having the build tools loaded.
> That is natural.
>
> What ELPA contains is not build tools for Emacs,
> but add-ons for Emacs.  It is not natural that building
> program A requires all its add-ons to be loaded.,


Richard

I think we are going around in circles here, so perhaps I can spell out
what I am suggesting.

Emacs is currently what we might call the "real core" and a large number
of packages. Then there is another number of packages in ELPA. Some
packages are in both. It's not necessarily clear why packages are in one
of the other. Operationally, packages in core are available in the
default download, while packages in ELPA are not; packages in ELPA are
easy to update by users between Emacs releases, packages in core are
not.  The only way to square this circle is to put packages in both ELPA
and core.

The changes I am suggesting would (eventually when finished) produce two
tar balls "emacs" and "emacs-with-elpa". The latter would come with
additional ELPA packages; it would only be generated with a configure
option but, of course, to build in this way would require access to
those ELPA packages. To build only the former would not require access
to those ELPA packages.

The eventual aim would be an Emacs where many of the packages currently
in core, become routinely updatable between release cycles. I think this
would appeal to many developers who would like their code to get into
the world quicker; but would still prefer the visibility that being in
the default download.

I think this is a good idea, but others do not. I hope you can see why,
though, I am talking about release cycles, access to ELPA packages and
building Emacs all at the same time. They are intimately linked in this
case.

Phil