* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
@ 2014-05-19 16:26 Drew Adams
2014-05-19 16:33 ` Drew Adams
2019-09-15 0:29 ` Stefan Kangas
0 siblings, 2 replies; 11+ messages in thread
From: Drew Adams @ 2014-05-19 16:26 UTC (permalink / raw)
To: 17530
The defcustom type is (repeat symbol), but the doc string says that it
should be a repetition of entries like this:
1. The symbol `all' (only).
2. List (NAME VERSION), where NAME is a symbol and VERSION is one of
these: t, a string, or nil.
So it is currently effectively impossible to customize this option.
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-04-29 on ODIEONE
Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2014-05-19 16:26 bug#17530: 24.4.50; `package-load-list': incorrect defcustom type Drew Adams
@ 2014-05-19 16:33 ` Drew Adams
2019-09-15 0:29 ` Stefan Kangas
1 sibling, 0 replies; 11+ messages in thread
From: Drew Adams @ 2014-05-19 16:33 UTC (permalink / raw)
To: 17530
And why is the default value `all'?
If someone does not customize this or does `package-initialize' in
their init file before loading `custom-file' then they might be in
for an unwelcome surprise, depending on what packages they have
locally.
The default value would be better as nil, IMHO.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2014-05-19 16:26 bug#17530: 24.4.50; `package-load-list': incorrect defcustom type Drew Adams
2014-05-19 16:33 ` Drew Adams
@ 2019-09-15 0:29 ` Stefan Kangas
2019-09-15 14:00 ` Drew Adams
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Kangas @ 2019-09-15 0:29 UTC (permalink / raw)
To: Drew Adams; +Cc: 17530-done
Drew Adams <drew.adams@oracle.com> writes:
> The defcustom type is (repeat symbol), but the doc string says that it
> should be a repetition of entries like this:
>
> 1. The symbol `all' (only).
> 2. List (NAME VERSION), where NAME is a symbol and VERSION is one of
> these: t, a string, or nil.
>
> So it is currently effectively impossible to customize this option.
This has subsequently been fixed:
commit 9be8a2fb41043b4d4734a67f155d6923df10671b
Author: Glenn Morris <rgm@gnu.org>
Date: Thu Jan 28 08:58:43 2016 -0800
* lisp/emacs-lisp/package.el (package-load-list): Improve :type.
I'm therefore closing this bug report.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 0:29 ` Stefan Kangas
@ 2019-09-15 14:00 ` Drew Adams
2019-09-15 15:37 ` Noam Postavsky
0 siblings, 1 reply; 11+ messages in thread
From: Drew Adams @ 2019-09-15 14:00 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 17530-done
> This has subsequently been fixed:
>
> commit 9be8a2fb41043b4d4734a67f155d6923df10671b
> Author: Glenn Morris <rgm@gnu.org>
> Date: Thu Jan 28 08:58:43 2016 -0800
>
> * lisp/emacs-lisp/package.el (package-load-list): Improve :type.
>
> I'm therefore closing this bug report.
OK; good that the :type spec was fixed.
But at least in Emacs 26.3, the default is still
`(all)'. For the record, this part of the problem
hasn't been addressed:
> If someone does not customize this or does
> `package-initialize' in their init file before
> loading `custom-file' then they might be in
> for an unwelcome surprise, depending on what
> packages they have locally.
>
> The default value would be better as nil, IMHO.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 14:00 ` Drew Adams
@ 2019-09-15 15:37 ` Noam Postavsky
2019-09-15 21:27 ` Drew Adams
0 siblings, 1 reply; 11+ messages in thread
From: Noam Postavsky @ 2019-09-15 15:37 UTC (permalink / raw)
To: Drew Adams; +Cc: Stefan Kangas, 17530
Drew Adams <drew.adams@oracle.com> writes:
> But at least in Emacs 26.3, the default is still
> `(all)'. For the record, this part of the problem
> hasn't been addressed:
>
>> If someone does not customize this or does
>> `package-initialize' in their init file before
>> loading `custom-file' then they might be in
>> for an unwelcome surprise, depending on what
>> packages they have locally.
>>
>> The default value would be better as nil, IMHO.
A default of nil would mean that no packages are loaded. So pretty much
anyone installing packages would have to customize it to `(all)' in
order to get their packages working. That sounds like a worse default.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 15:37 ` Noam Postavsky
@ 2019-09-15 21:27 ` Drew Adams
2019-09-15 21:39 ` Stefan Kangas
0 siblings, 1 reply; 11+ messages in thread
From: Drew Adams @ 2019-09-15 21:27 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Stefan Kangas, 17530
> > But at least in Emacs 26.3, the default is still
> > `(all)'. For the record, this part of the problem
> > hasn't been addressed:
> >
> >> If someone does not customize this or does
> >> `package-initialize' in their init file before
> >> loading `custom-file' then they might be in
> >> for an unwelcome surprise, depending on what
> >> packages they have locally.
> >>
> >> The default value would be better as nil, IMHO.
>
> A default of nil would mean that no packages are loaded.
No, just by default. No packages loaded by default.
> So pretty much anyone installing packages
No, anyone who wants to _load_ packages. You would
specify/configure which packages to load, yes. Is
that outlandish or too restrictive?
> would have to customize it to `(all)' in order to
> get their packages working. That sounds like a
> worse default.
Not to me, it doesn't. Just because you've installed
some packages doesn't mean you want them to all to be
loaded. That's a bit like automatically applying
`require' to everything you have in your `load-path'.
Why would we assume that, by default, users should
load the latest installed versions of all installed
packages?
Do I feel strongly about this? No. But it seems
wrong.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 21:27 ` Drew Adams
@ 2019-09-15 21:39 ` Stefan Kangas
2019-09-15 22:05 ` Drew Adams
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Kangas @ 2019-09-15 21:39 UTC (permalink / raw)
To: Drew Adams; +Cc: Noam Postavsky, 17530
Drew Adams <drew.adams@oracle.com> writes:
> > So pretty much anyone installing packages
>
> No, anyone who wants to _load_ packages. You would
> specify/configure which packages to load, yes. Is
> that outlandish or too restrictive?
It's too restrictive, yes. You have already specified that you want
to use them by installing them.
>> would have to customize it to `(all)' in order to
>> get their packages working. That sounds like a
>> worse default.
>
> Not to me, it doesn't. Just because you've installed
> some packages doesn't mean you want them to all to be
> loaded.
In this use case you would customize `package-initialize' to only load
what you're interested in.
> Why would we assume that, by default, users should
> load the latest installed versions of all installed
> packages?
Because that's what most users would expect, I think.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 21:39 ` Stefan Kangas
@ 2019-09-15 22:05 ` Drew Adams
2019-09-15 22:27 ` Stefan Kangas
2019-09-15 23:38 ` Noam Postavsky
0 siblings, 2 replies; 11+ messages in thread
From: Drew Adams @ 2019-09-15 22:05 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Noam Postavsky, 17530
> > > So pretty much anyone installing packages
> >
> > No, anyone who wants to _load_ packages. You would
> > specify/configure which packages to load, yes. Is
> > that outlandish or too restrictive?
>
> It's too restrictive, yes. You have already specified
> that you want to use them by installing them.
Really? How so? Installing isn't loading. Mightn't
a user install some packages that s?he doesn't want to
load?
After all, isn't that the _point_ of this user option?
A user might install packages at various times, for
various reasons. Why would it follow that s?he wants
to load them all by default?
Isn't "installing" essentially downloading, compiling,
and setting up autoloads? It doesn't imply loading,
AFAIK.
> >> would have to customize it to `(all)' in order to
> >> get their packages working. That sounds like a
> >> worse default.
> >
> > Not to me, it doesn't. Just because you've installed
> > some packages doesn't mean you want them to all to be
> > loaded.
>
> In this use case you would customize `package-initialize'
> to only load what you're interested in.
Customization can work for any use case. That doesn't
speak to what the default value should be. It's just
as arguable that if you want all then you customize to
`(all)'.
> > Why would we assume that, by default, users should
> > load the latest installed versions of all installed
> > packages?
>
> Because that's what most users would expect, I think.
I'm asking why you think that.
You don't think that most users would expect that all
libraries in their `load-path' should be loaded by
default, do you? (I don't.) If you don't, then why
do you think differently about installed packages?
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 22:05 ` Drew Adams
@ 2019-09-15 22:27 ` Stefan Kangas
2019-09-15 23:38 ` Noam Postavsky
1 sibling, 0 replies; 11+ messages in thread
From: Stefan Kangas @ 2019-09-15 22:27 UTC (permalink / raw)
To: Drew Adams; +Cc: Noam Postavsky, 17530
Drew Adams <drew.adams@oracle.com> writes:
> Really? How so? Installing isn't loading. Mightn't
> a user install some packages that s?he doesn't want to
> load?
>
> After all, isn't that the _point_ of this user option?
Yes, this defcustom exists to support the use case where a user wants
to specify which packages to load.
> > > Why would we assume that, by default, users should
> > > load the latest installed versions of all installed
> > > packages?
> >
> > Because that's what most users would expect, I think.
>
> I'm asking why you think that.
For starters, it's been the default for a long time. But more
importantly, the overwhelmingly common use case is that a user only
installs a package that he/she wants to use. That means that it has
to be loaded.
Of course, some users might install a package for other reasons.
Therefore it makes sense to allow them to specify exactly what
packages to load.
> You don't think that most users would expect that all
> libraries in their `load-path' should be loaded by
> default, do you? (I don't.) If you don't, then why
> do you think differently about installed packages?
Well, no, but I also don't think that this is a very good comparison.
In this case, you have to specify with a call to require that you want
to load it. In the package.el case, you specify it by installing it.
Nothing is loaded blindly or unexpectedly.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 22:05 ` Drew Adams
2019-09-15 22:27 ` Stefan Kangas
@ 2019-09-15 23:38 ` Noam Postavsky
2019-09-16 1:18 ` Drew Adams
1 sibling, 1 reply; 11+ messages in thread
From: Noam Postavsky @ 2019-09-15 23:38 UTC (permalink / raw)
To: Drew Adams; +Cc: Stefan Kangas, 17530
Drew Adams <drew.adams@oracle.com> writes:
> Isn't "installing" essentially downloading, compiling,
> and setting up autoloads? It doesn't imply loading,
> AFAIK.
package-load-list controls the "setting up autoloads" (and load-path)
part.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#17530: 24.4.50; `package-load-list': incorrect defcustom type
2019-09-15 23:38 ` Noam Postavsky
@ 2019-09-16 1:18 ` Drew Adams
0 siblings, 0 replies; 11+ messages in thread
From: Drew Adams @ 2019-09-16 1:18 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Stefan Kangas, 17530
> > Isn't "installing" essentially downloading, compiling,
> > and setting up autoloads? It doesn't imply loading,
> > AFAIK.
N> package-load-list controls the "setting up autoloads" (and load-path)
N> part.
OK.
S> the overwhelmingly common use case is that a user
S> only installs a package that he/she wants to use.
OK. I'll take your word for it. But it's not what I
expected.
I'm no expert on package.el or how most people use it.
It seemed odd to me that just installing should, by
default, also automatically load everything installed.
But I guess that's a misunderstanding on my part.
I use `load-path' and `require', and I've put tons of
stuff in my `load-path' that I rarely, if ever, load.
I imagined that many package users would similarly
install stuff they don't want to load systematically.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-09-16 1:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-19 16:26 bug#17530: 24.4.50; `package-load-list': incorrect defcustom type Drew Adams
2014-05-19 16:33 ` Drew Adams
2019-09-15 0:29 ` Stefan Kangas
2019-09-15 14:00 ` Drew Adams
2019-09-15 15:37 ` Noam Postavsky
2019-09-15 21:27 ` Drew Adams
2019-09-15 21:39 ` Stefan Kangas
2019-09-15 22:05 ` Drew Adams
2019-09-15 22:27 ` Stefan Kangas
2019-09-15 23:38 ` Noam Postavsky
2019-09-16 1:18 ` Drew Adams
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.