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

[phillip.lord@russet.org.uk (Phillip Lord)]

Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > > That avoids the problem I thought I saw, but what is the purpose?  I
>   > > thought the idea of ELPA is that a user would get ELPA packages when perse
>   > > wants them -- they would not be preloaded.
>
>   > Perhaps. An alternative, though, would be to reduce the size of Emacs as
>   > a monolithic entity and have many more packages that are distributed via
>   > ELPA. At the moment, the slow release cycle of Emacs means that many
>   > packages are only updated on a two yearly basis.
>
> I don't see how one is an alternative to the other.  They seem
> to be talking about two different questions, both about ELPA
> but not the same.

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.


>   > > Is this a way of handling a few packages that are included in Emacs
>   > > distros, if we maintain them in ELPA?  It makes a kind of sense for
>   > > that case, but I would expect that those testing and making Emacs
>   > > releases would need more control over which versions of packages are
>   > > included in the release.
>
>   > Yes, although as I say, with the intention of enabling more packages to
>   > be developed in this way. I'm not sure how many packages are currently
>   > included in both repos (org and seq for sure).
>
> How many there will be is a different question.  The question at hand
> is how to handle merging them into Emacs and when.
>
> 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. Org-mode is managed in both places for this reason: in core Emacs
because it comes "pre-installed" with all Emacs releases; in ELPA
because newer version of org-mode can be installed easily by users.

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.


>   > > If installing Emacs doesn't require a local copy of ELPA, building
>   > > Emacs should not need one.
>
>   > Building Emacs requires lots of things that installing does not.
>
> 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.


>   > I think this is wrong. Having stuff which is not really source (i.e. it
>   > is not the prefered location for editing)
>
> It is source code, no matter where it is located.  It is source code
> even when it is a copy the user has downloaded.
>
> Pastiching our definition of source code could be a good joke, but it
> is not a serious argument for a decision about development methods.

I am happy to use an alternative label if you have one. A flaw with this
alternative system is that, for example, the "jump to source" link in
*Help* will take you to a piece of lisp that you do not want to edit
because it may be over written.

Phil