From: Radon Rosborough <radon.neon@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: "Clément Pit-Claudel" <cpitclaudel@gmail.com>, emacs-devel@gnu.org
Subject: Re: Summary and next steps for (package-initialize)
Date: Wed, 23 Aug 2017 17:44:52 -0700 [thread overview]
Message-ID: <CADB4rJG_gqAVuGh7rM3DbmJ3HJbwaLDpm3L7rdwXn5Ny6qjkDQ@mail.gmail.com> (raw)
In-Reply-To: <7acb6970-cbc4-48b2-84c7-afee108d689f@default>
[-- Attachment #1: Type: text/plain, Size: 4492 bytes --]
> > And we also expect libraries installed using package.el to work
> > similarly to libraries that are shipped with Emacs.
>
> Dunno what that means. Work similarly how? How could they work
> differently?
Libraries that are shipped with Emacs are made available automatically
without anything needing to be put in the init-file. And this happens
during startup, before the init-file is loaded.
OTOH, if package.el needs to be set up manually, as you propose, then
libraries that are installed using package.el would not be made
available automatically unless (package-initialize) was in the user's
init-file, and they would not be made available until part-way through
the loading of the init-file.
Now you may prefer the latter, but you can't argue that it's more
consistent behavior.
> Why does enabling it by default follow from wanting libraries
> installed by it to "work similarly" to libraries shipped with Emacs?
Is this clear now?
> I still haven't seen an argument why we shouldn't have users opt in
> to turn on use of the package system.
It's because most people want to use the package system (you admitted
this yourself). As you observed, we have a large assortment of tidbits
in Emacs core, and whether they are enabled by default depends on
whether most users want them enabled by default.
> `cua-mode' is not turned on by default. Yet its behavior is used by
> 90% of users outside of Emacs.
Irrelevant. Most people don't use it *inside* of Emacs, so it's
disabled by default.
> `delete-selection-mode' is not turned on by default (but it should
> be).
I'm not saying the decisions about defaults have been made flawlessly.
But it's pretty hard to argue that it's more common to want the
package manager disabled than it is to want it enabled. Defaults are
supposed to eliminate work for the user; what good are they if they
don't align with what most people want?
> > (setq package-enable-at-startup nil)
>
> I'll certainly do that. Along with (electric-indent-mode -1).
As I'm sure you're aware, you're very much in the minority in both of
these things. So you probably shouldn't be surprised that the defaults
are not suitable for you. I'm aware that I'm in the minority in using
a package manager other than package.el, so I have no qualms with
having to override the defaults.
> (But apparently I'll need to put the `package-enable-at-startup'
> setting in another, "secondary" init file, as an exception. Not a
> big deal. Kinda clunky though.)
Agreed, it's clunky. But also agreed, it's not a big deal: and
considering how many other problems we solve by doing it this way, I
think it's a pretty good tradeoff to make.
> Why isn't the package-system doc improvement started, as the first
> thing to do?
Because the current situation (Emacs modifies the user's init-file) is
a catastrophe, and fixing that is an ASAP priority. Also, people (e.g.
Mark Oteiza) are reluctant to document package.el when the current
behavior is clearly broken.
> Seems like that would be a good thing for those who are familiar
> with the package mgr and are strong proponents of it to work on.
I agree but the docs improvements are orthogonal to fixing the code.
Indeed, improving the documentation would be our top priority if we
were going to disable package.el by default, which is what you want.
But we're not going to do that (based on what I've heard from everyone
else), so the docs are not necessarily our top priority.
> > I'd like us to give more visibility to Emacs packages, because I
> > commonly run into people who use package in Atom or Visual Studio
> > Code, but not in Emacs (and that's not because Emacs provides the
> > corresponding features without an extra packages)
>
> That is *not* a great reason to enable something by default.
Actually, it's a great reason. You know how GitHub is kicking GNU's
tail in marketing Atom? Well, "built-in package manager" is literally
on the front page of their website, right next to "use productively
without ever touching a config file". I'd say this is an indication
that people care very much indeed about their text editor coming with
a package manager that works right out of the box.
> Emacs users know both.
No, they don't. At least not the sort of users we want to attract, who
don't know anything about Emacs. Yes, all the people on emacs-devel
know this stuff, but emacs-devel is about 1% of Emacs users, and about
0.01% of the Emacs users we could have if Emacs worked better out of
the box.
[-- Attachment #2: Type: text/html, Size: 5951 bytes --]
next prev parent reply other threads:[~2017-08-24 0:44 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 2:38 Summary and next steps for (package-initialize) Radon Rosborough
2017-08-20 6:10 ` Drew Adams
2017-08-20 17:20 ` Radon Rosborough
2017-08-20 18:09 ` Drew Adams
2017-08-20 18:39 ` Radon Rosborough
2017-08-21 0:33 ` Drew Adams
2017-08-21 4:08 ` Radon Rosborough
2017-08-20 8:13 ` Stefan Monnier
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 8:15 ` Clément Pit-Claudel
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 14:20 ` Eli Zaretskii
2017-08-20 16:37 ` Alex
2017-08-20 16:44 ` Eli Zaretskii
2017-08-20 16:46 ` Yuri Khan
2017-08-20 16:54 ` Drew Adams
2017-08-20 17:18 ` Colin Baxter
2017-08-22 21:24 ` Alex
2017-08-20 17:22 ` Radon Rosborough
2017-08-20 17:36 ` Eli Zaretskii
2017-08-20 17:54 ` Radon Rosborough
2017-08-21 16:35 ` Eli Zaretskii
2017-08-21 16:43 ` Radon Rosborough
2017-08-21 17:40 ` Eli Zaretskii
2017-08-21 20:33 ` Radon Rosborough
2017-08-22 2:37 ` Eli Zaretskii
2017-08-22 4:52 ` Radon Rosborough
2017-08-22 8:41 ` Clément Pit-Claudel
2017-08-22 16:02 ` Radon Rosborough
2017-08-22 14:33 ` Eli Zaretskii
2017-08-22 18:09 ` Radon Rosborough
2017-08-22 21:01 ` Clément Pit-Claudel
2017-08-21 9:04 ` Stefan Monnier
2017-08-21 14:31 ` Eli Zaretskii
2017-08-21 16:34 ` Radon Rosborough
2017-08-21 17:47 ` Clément Pit-Claudel
2017-08-22 11:37 ` Timur Aydin
2017-08-22 16:58 ` Radon Rosborough
2017-08-22 21:04 ` Clément Pit-Claudel
2017-08-23 5:17 ` Radon Rosborough
2017-08-23 11:33 ` Angelo Graziosi
2017-08-23 17:16 ` Radon Rosborough
2017-08-23 13:28 ` Drew Adams
2017-08-23 17:31 ` Radon Rosborough
2017-08-23 18:00 ` Drew Adams
2017-08-23 18:32 ` Radon Rosborough
2017-08-23 20:27 ` Drew Adams
2017-08-23 20:59 ` Clément Pit-Claudel
2017-08-23 21:21 ` Drew Adams
2017-08-23 21:44 ` Clément Pit-Claudel
2017-08-23 21:53 ` Drew Adams
2017-08-24 0:44 ` Radon Rosborough [this message]
2017-08-24 6:39 ` Drew Adams
2017-08-25 1:03 ` Radon Rosborough
2017-08-24 17:14 ` Eli Zaretskii
[not found] ` <<83fucg99cj.fsf@gnu.org>
2017-08-24 17:44 ` Drew Adams
2017-08-24 18:12 ` Clément Pit-Claudel
2017-08-24 18:29 ` Drew Adams
2017-08-24 21:34 ` Clément Pit-Claudel
2017-08-24 21:40 ` Drew Adams
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 18:14 ` Eli Zaretskii
[not found] ` <<83bmn496js.fsf@gnu.org>
2017-08-24 18:36 ` Drew Adams
2017-08-24 18:57 ` Eli Zaretskii
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 1:04 ` Radon Rosborough
2017-08-23 3:15 ` Stefan Monnier
2017-08-24 16:47 ` Eli Zaretskii
2017-08-24 17:48 ` Stefan Monnier
2017-08-24 18:26 ` Eli Zaretskii
2017-08-25 3:52 ` Stefan Monnier
2017-08-25 3:59 ` Radon Rosborough
2017-08-25 4:39 ` Stefan Monnier
2017-08-25 4:45 ` Radon Rosborough
2017-08-25 4:48 ` Stefan Monnier
2017-08-25 6:47 ` Eli Zaretskii
2017-08-25 11:51 ` Stefan Monnier
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 4:14 ` Stefan Monnier
2017-08-25 4:28 ` Radon Rosborough
2017-08-25 4:47 ` Stefan Monnier
2017-08-25 21:07 ` Stefan Monnier
2017-08-25 21:34 ` Radon Rosborough
2017-08-26 22:29 ` Stefan Monnier
2017-08-26 22:33 ` Radon Rosborough
2017-08-21 16:18 ` Radon Rosborough
2017-08-20 19:09 ` Mark Oteiza
2017-08-23 15:57 ` Nikolay Kudryavtsev
2017-08-23 18:17 ` Radon Rosborough
2017-08-23 19:17 ` Nikolay Kudryavtsev
2017-08-23 19:38 ` Radon Rosborough
2017-08-23 20:09 ` Nikolay Kudryavtsev
2017-08-24 0:13 ` Radon Rosborough
2017-08-24 13:44 ` Nikolay Kudryavtsev
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 17:12 ` Eli Zaretskii
2017-08-23 22:30 ` Nathan Moreau
2017-08-24 0:54 ` Radon Rosborough
2017-08-24 11:13 ` Nathan Moreau
2017-08-24 17:02 ` Eli Zaretskii
2017-08-24 17:52 ` Nikolay Kudryavtsev
2017-08-24 18:31 ` Eli Zaretskii
2017-08-25 13:48 ` Nikolay Kudryavtsev
-- strict thread matches above, loose matches on Subject: below --
2017-08-21 8:24 angelo.g0
2017-08-21 16:22 ` Radon Rosborough
2017-08-21 19:35 ` Angelo Graziosi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADB4rJG_gqAVuGh7rM3DbmJ3HJbwaLDpm3L7rdwXn5Ny6qjkDQ@mail.gmail.com \
--to=radon.neon@gmail.com \
--cc=cpitclaudel@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.