Re: PL support

[Stefan Kangas]

Eli Zaretskii <address@hidden> writes:

>> Having a package on ELPA is not as good as having it in the core (for example
>> Magit), but it’s much better than having the user to force them to use MELPA
>> as soon as they start using Emacs.
>
> Why? what's wrong with using MELPA?

The main problem for me flows from the fact that we can't configure
MELPA by default nor even recommend it prominently in the manual and on
the website.  There are packages on MELPA which IMHO could be extremely
beneficial to install for beginning users, for example, but we can't
tell our users about them.[1]

For many users (me included), using Emacs without packages from MELPA
would mean missing out on functionality you depend on for carrying out
your daily work.  We are not really delivering the "full Emacs package"
as is, nor do we tell our users how to get there.  Instead, we ask them
to rely on third-party sources, wikis, blogs and chat rooms to fill in
the blanks left by our documentation and default configuration.

I also think it's strategically bad if we want more people assign their
code and get more people involved in Emacs development.  The way to do
that is surely to do everything we can to pull package developers closer
to us, not just tell them to stay in MELPA.

(I don't think the best option is to start recommending MELPA, by the
way.  We would be better off if we distributed certain packages from an
official GNU archive, such as "ELPA" or "ELPA-contrib" as I suggested
before.)

Best regards,
Stefan Kangas

Footnotes:
[1] For me, this is also connected to the discussion about better
     onboarding, which could be improved by recommending certain
     packages for your use-case.  For example, if you tell Emacs you
     want to code PHP, you should probably be pointed to `php-mode'
     (only available on MELPA).  Or: "If you want to use git, why not
     try the built-in 'vc' or the third-party package 'magit' (or use
     both)."