Customizable modes and package.el

Customizable modes and package.el

[Sebastian Wiesner]

Hello,

I have a globalized minor mode defined as follows:

(define-globalized-minor-mode global-flycheck-mode flycheck-mode
  flycheck-mode-on-safe
  :init-value nil
  :group 'flycheck
  :require 'flycheck)

If my understanding is correct, users should now be able to enable
"global-flycheck-mode" through the customize interface, shouldn't
they?  After all, I can see the mode in customize, enable it, and
Emacs writes the following form to my init file:

(custom-set-variables
...
 '(global-flycheck-mode t nil (flycheck))
 ...

Now, my users usually install my package via ELPA, and by default,
ELPA packages do not become available until *after* the init file was
loaded.

Consequently, the above form fails to load, since customize tries to
load a library which isn't available yet. I read the documentation on
customize again, but I didn't find anything related to package.el at
all.

What did I do wrong?

Greetings,
Sebastian

Re: Customizable modes and package.el

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Sebastian Wiesner <swiesner@lunaryorn.com> schrieb am Sa., 28. März 2015 um
09:58 Uhr:

> Hello,
>
> I have a globalized minor mode defined as follows:
>
> (define-globalized-minor-mode global-flycheck-mode flycheck-mode
>   flycheck-mode-on-safe
>   :init-value nil
>   :group 'flycheck
>   :require 'flycheck)
>
> If my understanding is correct, users should now be able to enable
> "global-flycheck-mode" through the customize interface, shouldn't
> they?  After all, I can see the mode in customize, enable it, and
> Emacs writes the following form to my init file:
>
> (custom-set-variables
> ...
>  '(global-flycheck-mode t nil (flycheck))
>  ...
>
> Now, my users usually install my package via ELPA, and by default,
> ELPA packages do not become available until *after* the init file was
> loaded.
>
> Consequently, the above form fails to load, since customize tries to
> load a library which isn't available yet. I read the documentation on
> customize again, but I didn't find anything related to package.el at
> all.
>
>

Probably because package.el started as a third-party library that is newer
than custom.el.
Now that package.el is part of Emacs, their interaction could be improved.
Perhaps custom-theme-set-variables could do two-phase initialization: if
requiring a feature fails, the initialization of the variable is retried
after package-initialize has been executed.

[-- Attachment #2: Type: text/html, Size: 1803 bytes --]

Re: Customizable modes and package.el

[Stefan Monnier]

> Now, my users usually install my package via ELPA, and by default,
> ELPA packages do not become available until *after* the init file was
> loaded.

> What did I do wrong?

You forgot to tell them to add

    (package-initialize)

at the beginning of their ~/.emacs.

And yes, the user shouldn't have to do that by hand, but currently,
that's where we're at.


        Stefan

Re: Customizable modes and package.el

[Sebastian Wiesner]

2015-03-28 13:26 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Now, my users usually install my package via ELPA, and by default,
>> ELPA packages do not become available until *after* the init file was
>> loaded.
>
>> What did I do wrong?
>
> You forgot to tell them to add
>
>     (package-initialize)
>
> at the beginning of their ~/.emacs.

If I am to tell them that, I might just as well tell them to simply
use "(add-hook 'after-init-hook #'global-flycheck-mode)".

Correct me if I'm wrong, but isn't one of the purposes of customize to
avoid the need to manually add code to your init file?

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

> Correct me if I'm wrong, but isn't one of the purposes of customize to
> avoid the need to manually add code to your init file?

"yes, the user shouldn't have to do that by hand"

I can try my hand at implementing Philipp's suggestion, if people agree
with the idea.

Artur

[-- Attachment #2: Type: text/html, Size: 386 bytes --]

Re: Customizable modes and package.el

[Stefan Monnier]

> I can try my hand at implementing Philipp's suggestion, if people agree
> with the idea.

I think it's worth a try, yes.  I think the design space is pretty
large, so feel free to send a rough proof-of-concept before investing
time into cleaning it up.


        Stefan

Re: Customizable modes and package.el

[Artur Malabarba]

Initial draft

The only thing I'm totally sure on is the `now' parameter. I think
it's not a problem, because it's meant to indicate "set the value
wihout waiting for the defcustom" and not "set the value immediately",
but I don't know its real use-case, so it's hard to say for sure.

diff --git a/lisp/custom.el b/lisp/custom.el
index e5fe0eb..d07f0c0 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -933,6 +933,37 @@ handle SYMBOL properly.
 COMMENT is a comment string about SYMBOL."
   (apply 'custom-theme-set-variables 'user args))

+(defun custom--load-entry (entry &optional requests)
+  "Load custom ENTRY, after requiring all features in REQUESTS.
+Signal a meaningful error if any of the features are absent."
+  ;; Now set the variable.
+  (let* ((now (nth 2 entry))
+         (comment (nth 4 entry))
+         (symbol (indirect-variable (nth 0 entry)))
+         (value (nth 1 entry))
+         set)
+    (dolist (f requests)
+      (unless (require f nil t)
+        (error "Cannot find load file `%s', required by `%s' inside your `%s'"
+               f symbol 'custom-set-variables)))
+    (setq set (or (get symbol 'custom-set) 'custom-set-default))
+    (put symbol 'saved-value (list value))
+    (put symbol 'saved-variable-comment comment)
+    ;; Allow for errors in the case where the setter has
+    ;; changed between versions, say, but let the user know.
+    (condition-case data
+        (cond (now
+               ;; Rogue variable, set it now.
+               (put symbol 'force-value t)
+               (funcall set symbol (eval value)))
+              ((default-boundp symbol)
+               ;; Something already set this, overwrite it.
+               (funcall set symbol (eval value))))
+      (error
+          (message "Error setting %s: %s" symbol data)))
+    (and (or now (default-boundp symbol))
+         (put symbol 'variable-comment comment))))
+
 (defun custom-theme-set-variables (theme &rest args)
   "Initialize variables for theme THEME according to settings in ARGS.
 Each of the arguments in ARGS should be a list of this form:
@@ -972,31 +1003,16 @@ COMMENT is a comment string about SYMBOL."
        (value (nth 1 entry)))
       (custom-push-theme 'theme-value symbol theme 'set value)
       (unless custom--inhibit-theme-enable
-    ;; Now set the variable.
-    (let* ((now (nth 2 entry))
-           (requests (nth 3 entry))
-           (comment (nth 4 entry))
-           set)
-      (when requests
-        (put symbol 'custom-requests requests)
-        (mapc 'require requests))
-      (setq set (or (get symbol 'custom-set) 'custom-set-default))
-      (put symbol 'saved-value (list value))
-      (put symbol 'saved-variable-comment comment)
-      ;; Allow for errors in the case where the setter has
-      ;; changed between versions, say, but let the user know.
-      (condition-case data
-          (cond (now
-             ;; Rogue variable, set it now.
-             (put symbol 'force-value t)
-             (funcall set symbol (eval value)))
-            ((default-boundp symbol)
-             ;; Something already set this, overwrite it.
-             (funcall set symbol (eval value))))
-        (error
-         (message "Error setting %s: %s" symbol data)))
-      (and (or now (default-boundp symbol))
-           (put symbol 'variable-comment comment)))))))
+        (let* ((requests (nth 3 entry)))
+          (when requests
+            (put symbol 'custom-requests requests))
+          ;; If a symbol has requirements, we don't even try to load
+          ;; them now, because we might accidentally load an old
+          ;; built-in instead of a newer installed version.
+          (if requests
+              (add-hook 'after-init-hook
+                        (apply-partially #'custom--load-entry entry requests))
+            (custom--load-entry entry)))))))

 (defvar custom--sort-vars-table)
 (defvar custom--sort-vars-result)

Re: Customizable modes and package.el

[Stefan Monnier]

> The only thing I'm totally sure on is the `now' parameter. I think
> it's not a problem, because it's meant to indicate "set the value
> wihout waiting for the defcustom" and not "set the value immediately",
> but I don't know its real use-case, so it's hard to say for sure.

Hmm... I thought the idea was to add "(package-initialize)" to the
~/.emacs


        Stefan


> diff --git a/lisp/custom.el b/lisp/custom.el
> index e5fe0eb..d07f0c0 100644
> --- a/lisp/custom.el
> +++ b/lisp/custom.el
> @@ -933,6 +933,37 @@ handle SYMBOL properly.
>  COMMENT is a comment string about SYMBOL."
>    (apply 'custom-theme-set-variables 'user args))

> +(defun custom--load-entry (entry &optional requests)
> +  "Load custom ENTRY, after requiring all features in REQUESTS.
> +Signal a meaningful error if any of the features are absent."
> +  ;; Now set the variable.
> +  (let* ((now (nth 2 entry))
> +         (comment (nth 4 entry))
> +         (symbol (indirect-variable (nth 0 entry)))
> +         (value (nth 1 entry))
> +         set)
> +    (dolist (f requests)
> +      (unless (require f nil t)
> +        (error "Cannot find load file `%s', required by `%s' inside your `%s'"
> +               f symbol 'custom-set-variables)))
> +    (setq set (or (get symbol 'custom-set) 'custom-set-default))
> +    (put symbol 'saved-value (list value))
> +    (put symbol 'saved-variable-comment comment)
> +    ;; Allow for errors in the case where the setter has
> +    ;; changed between versions, say, but let the user know.
> +    (condition-case data
> +        (cond (now
> +               ;; Rogue variable, set it now.
> +               (put symbol 'force-value t)
> +               (funcall set symbol (eval value)))
> +              ((default-boundp symbol)
> +               ;; Something already set this, overwrite it.
> +               (funcall set symbol (eval value))))
> +      (error
> +          (message "Error setting %s: %s" symbol data)))
> +    (and (or now (default-boundp symbol))
> +         (put symbol 'variable-comment comment))))
> +
>  (defun custom-theme-set-variables (theme &rest args)
>    "Initialize variables for theme THEME according to settings in ARGS.
>  Each of the arguments in ARGS should be a list of this form:
> @@ -972,31 +1003,16 @@ COMMENT is a comment string about SYMBOL."
>         (value (nth 1 entry)))
>        (custom-push-theme 'theme-value symbol theme 'set value)
>        (unless custom--inhibit-theme-enable
> -    ;; Now set the variable.
> -    (let* ((now (nth 2 entry))
> -           (requests (nth 3 entry))
> -           (comment (nth 4 entry))
> -           set)
> -      (when requests
> -        (put symbol 'custom-requests requests)
> -        (mapc 'require requests))
> -      (setq set (or (get symbol 'custom-set) 'custom-set-default))
> -      (put symbol 'saved-value (list value))
> -      (put symbol 'saved-variable-comment comment)
> -      ;; Allow for errors in the case where the setter has
> -      ;; changed between versions, say, but let the user know.
> -      (condition-case data
> -          (cond (now
> -             ;; Rogue variable, set it now.
> -             (put symbol 'force-value t)
> -             (funcall set symbol (eval value)))
> -            ((default-boundp symbol)
> -             ;; Something already set this, overwrite it.
> -             (funcall set symbol (eval value))))
> -        (error
> -         (message "Error setting %s: %s" symbol data)))
> -      (and (or now (default-boundp symbol))
> -           (put symbol 'variable-comment comment)))))))
> +        (let* ((requests (nth 3 entry)))
> +          (when requests
> +            (put symbol 'custom-requests requests))
> +          ;; If a symbol has requirements, we don't even try to load
> +          ;; them now, because we might accidentally load an old
> +          ;; built-in instead of a newer installed version.
> +          (if requests
> +              (add-hook 'after-init-hook
> +                        (apply-partially #'custom--load-entry entry requests))
> +            (custom--load-entry entry)))))))

>  (defvar custom--sort-vars-table)
>  (defvar custom--sort-vars-result)

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 4762 bytes --]

If that's the path we're taking, I'd rather simply have package-initialize
be called before loading the init file, instead of after.
I understand the reasoning behind the easy it is now, but it's done way
more harm than good. The amount of people we see manually adding Elpa
packages to their load-path is appalling.
On Mar 30, 2015 1:41 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

> > The only thing I'm totally sure on is the `now' parameter. I think
> > it's not a problem, because it's meant to indicate "set the value
> > wihout waiting for the defcustom" and not "set the value immediately",
> > but I don't know its real use-case, so it's hard to say for sure.
>
> Hmm... I thought the idea was to add "(package-initialize)" to the
> ~/.emacs
>
>
>         Stefan
>
>
> > diff --git a/lisp/custom.el b/lisp/custom.el
> > index e5fe0eb..d07f0c0 100644
> > --- a/lisp/custom.el
> > +++ b/lisp/custom.el
> > @@ -933,6 +933,37 @@ handle SYMBOL properly.
> >  COMMENT is a comment string about SYMBOL."
> >    (apply 'custom-theme-set-variables 'user args))
>
> > +(defun custom--load-entry (entry &optional requests)
> > +  "Load custom ENTRY, after requiring all features in REQUESTS.
> > +Signal a meaningful error if any of the features are absent."
> > +  ;; Now set the variable.
> > +  (let* ((now (nth 2 entry))
> > +         (comment (nth 4 entry))
> > +         (symbol (indirect-variable (nth 0 entry)))
> > +         (value (nth 1 entry))
> > +         set)
> > +    (dolist (f requests)
> > +      (unless (require f nil t)
> > +        (error "Cannot find load file `%s', required by `%s' inside
> your `%s'"
> > +               f symbol 'custom-set-variables)))
> > +    (setq set (or (get symbol 'custom-set) 'custom-set-default))
> > +    (put symbol 'saved-value (list value))
> > +    (put symbol 'saved-variable-comment comment)
> > +    ;; Allow for errors in the case where the setter has
> > +    ;; changed between versions, say, but let the user know.
> > +    (condition-case data
> > +        (cond (now
> > +               ;; Rogue variable, set it now.
> > +               (put symbol 'force-value t)
> > +               (funcall set symbol (eval value)))
> > +              ((default-boundp symbol)
> > +               ;; Something already set this, overwrite it.
> > +               (funcall set symbol (eval value))))
> > +      (error
> > +          (message "Error setting %s: %s" symbol data)))
> > +    (and (or now (default-boundp symbol))
> > +         (put symbol 'variable-comment comment))))
> > +
> >  (defun custom-theme-set-variables (theme &rest args)
> >    "Initialize variables for theme THEME according to settings in ARGS.
> >  Each of the arguments in ARGS should be a list of this form:
> > @@ -972,31 +1003,16 @@ COMMENT is a comment string about SYMBOL."
> >         (value (nth 1 entry)))
> >        (custom-push-theme 'theme-value symbol theme 'set value)
> >        (unless custom--inhibit-theme-enable
> > -    ;; Now set the variable.
> > -    (let* ((now (nth 2 entry))
> > -           (requests (nth 3 entry))
> > -           (comment (nth 4 entry))
> > -           set)
> > -      (when requests
> > -        (put symbol 'custom-requests requests)
> > -        (mapc 'require requests))
> > -      (setq set (or (get symbol 'custom-set) 'custom-set-default))
> > -      (put symbol 'saved-value (list value))
> > -      (put symbol 'saved-variable-comment comment)
> > -      ;; Allow for errors in the case where the setter has
> > -      ;; changed between versions, say, but let the user know.
> > -      (condition-case data
> > -          (cond (now
> > -             ;; Rogue variable, set it now.
> > -             (put symbol 'force-value t)
> > -             (funcall set symbol (eval value)))
> > -            ((default-boundp symbol)
> > -             ;; Something already set this, overwrite it.
> > -             (funcall set symbol (eval value))))
> > -        (error
> > -         (message "Error setting %s: %s" symbol data)))
> > -      (and (or now (default-boundp symbol))
> > -           (put symbol 'variable-comment comment)))))))
> > +        (let* ((requests (nth 3 entry)))
> > +          (when requests
> > +            (put symbol 'custom-requests requests))
> > +          ;; If a symbol has requirements, we don't even try to load
> > +          ;; them now, because we might accidentally load an old
> > +          ;; built-in instead of a newer installed version.
> > +          (if requests
> > +              (add-hook 'after-init-hook
> > +                        (apply-partially #'custom--load-entry entry
> requests))
> > +            (custom--load-entry entry)))))))
>
> >  (defvar custom--sort-vars-table)
> >  (defvar custom--sort-vars-result)
>

[-- Attachment #2: Type: text/html, Size: 6119 bytes --]

Re: Customizable modes and package.el

[Stefan Monnier]

> If that's the path we're taking, I'd rather simply have package-initialize
> be called before loading the init file, instead of after.

That's not an option, because the user may need/want to run some Elisp
code of his own choosing *before* package-initialize is called.
E.g. in my case, I need to set package-load-list and
package-directory-list before package-initialize runs.


        Stefan

Re: Customizable modes and package.el

[Artur Malabarba]

> That's not an option, because the user may need/want to run some Elisp
> code of his own choosing *before* package-initialize is called.
> E.g. in my case, I need to set package-load-list and
> package-directory-list before package-initialize runs.

`package-initialize' could look into some file like
~/.emacs.d/package-init.el and load that before initializing.

Re: Customizable modes and package.el

[Robert Pluim]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> That's not an option, because the user may need/want to run some Elisp
>> code of his own choosing *before* package-initialize is called.
>> E.g. in my case, I need to set package-load-list and
>> package-directory-list before package-initialize runs.
>
> `package-initialize' could look into some file like
> ~/.emacs.d/package-init.el and load that before initializing.

Please, not Yet Another File That Changes Emacs' Behaviour

Robert

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

> >> That's not an option, because the user may need/want to run some Elisp
> >> code of his own choosing *before* package-initialize is called.
> >> E.g. in my case, I need to set package-load-list and
> >> package-directory-list before package-initialize runs.
> >
> > `package-initialize' could look into some file like
> > ~/.emacs.d/package-init.el and load that before initializing.
>
> Please, not Yet Another File That Changes Emacs' Behaviour

The file would not exist unless the user manually created it.

I'm not thrilled at this solution, and I'm open to alternatives, but we
have to do something.

This package.el-induced "cannot find load file" error is the most
predominant issue I see people run into in the wild. Some people file
issues for this stuff on github, others go to the relevant forums, and
others (I can only imagine) probably just give up on configuring packages
(or give up Emacs!) entirely.

We would be sparing a LOT of man-hours (from newbiews and from the experts
who help them) if we found a solution for this conundrum.

[-- Attachment #2: Type: text/html, Size: 1301 bytes --]

RE: Customizable modes and package.el

[Drew Adams]

> > > `package-initialize' could look into some file like
> > > ~/.emacs.d/package-init.el and load that before initializing.
> >
> > Please, not Yet Another File That Changes Emacs' Behaviour
> The file would not exist unless the user manually created it. 
> I'm not thrilled at this solution, and I'm open to alternatives, 
> but we have to do something. 

This thread was started with a question about using Customize
instead of requiring users to put Lisp code in their init files.

The user asked, "What did I do wrong?"  The answer is apparently
that Emacs is not yet ready for you to use Customize to configure
your use of package.el.

That's what should be done, IMO, whether now or later: enable
users to configure their use of package.el using Customize,
without resorting to Lisp in init files.

If for some reason that is not possible for all use cases, it
should still be a goal for the most common use cases.

I'd be among the first to say that good use of Emacs is very
much about making use of Emacs Lisp, but do we need to force
users to put code in their init files in order to make good use
of the package system?

Re: Customizable modes and package.el

[Stefan Monnier]

>>> That's not an option, because the user may need/want to run some Elisp
>>> code of his own choosing *before* package-initialize is called.
>>> E.g. in my case, I need to set package-load-list and
>>> package-directory-list before package-initialize runs.
>> `package-initialize' could look into some file like
>> ~/.emacs.d/package-init.el and load that before initializing.
> Please, not Yet Another File That Changes Emacs' Behaviour

Exactly.  So, for these reasons, "the solution" is to add
"(package-initialize)" in the ~/.emacs file.

Yes, this solution also sucks in some ways, but there's no perfect
solution, and this one is the most Emacs-ish solution, since it is
simple, and gives the most flexibility.


        Stefan

Re: Customizable modes and package.el

[David Reitter]

On Mar 30, 2015, at 1:28 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>> That's not an option, because the user may need/want to run some Elisp
>>>> code of his own choosing *before* package-initialize is called.
>>>> E.g. in my case, I need to set package-load-list and
>>>> package-directory-list before package-initialize runs.
>>> `package-initialize' could look into some file like
>>> ~/.emacs.d/package-init.el and load that before initializing.
>> Please, not Yet Another File That Changes Emacs' Behaviour
> 
> Exactly.  So, for these reasons, "the solution" is to add
> "(package-initialize)" in the ~/.emacs file.

See also Bug#21858.

Adding (package-initialize) to a user-controlled file is ugly if it has the consequence that it breaks startup of any older Emacs on the system.  
Also, note that the action is not undoable from the menus, even though installing a package can be done via the menu.

Simple kludge:

(if (fboundp ‘package-initialize) (package-initialize))

But, reasonably:

Treat .emacs as something only the user changes.  `custom-file’ is what can be changed by Emacs. (But that one is loaded too late,  in this case.)

If packages are present, can’t (package-initialize) be called unconditionally before .emacs is loaded?   In response to Stefan Monnier’s message from 3/30/2015, perhaps package-load-list and package-directory-list can be set elsewhere, or their functionality eliminated.   Or they could be set in .emacs with a new macro such as 

(eval-before-load 
	(setq package-load-list …))

or even

(set-package-load-list XXX)
(set-package-directory-list YYY)

Even the ~/.emacs.d/package-init.el file proposed by Artur seems more reasonable than what is done now, and it wouldn’t require an extra pass over the user’s .emacs.

Re: Customizable modes and package.el

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

I also concur that emacs should not try to modify the user's init file.

[-- Attachment #2: Type: text/html, Size: 94 bytes --]

RE: Customizable modes and package.el

[Drew Adams]

> I also concur that emacs should not try to modify the user's init file.

+1.

Customize can modify `custom-file'.  `bookmark.el' can modify
a user's bookmarks file(s).  `desktop.el' can modify a user's
desktop file(s).  `package.el' can modify package-related files...

But programmatic changes should not diddle with a user's init file.

The way things are now (still), such diddling is the default
behavior for Customize.  Shame.

To prevent this, a user needs to create and load a `custom-file'.

And s?he won't even find out about this possibility without
diving into the depths of the Customize section of the Emacs
manual.  Looking at node `Init File' won't give a clue about
this safer and more sane possibility.

My guess is that relatively few Emacs users have a `custom-file'.
Most just let Customize write to their init files (if they use
Customize at all).  That's not good.

Imagine if `bookmark.el', `desktop.el', and all the rest
wrote all of their Lisp code directly to a users init file!
It's high time that Customize learned to behave the same way.

Yes, this would mean that users would need to load their
`custom-file' somewhere in their init file.  And yes, just
where they choose to do that in the init file can make a
difference.  And yes, there are different use cases - it
is not as simple as always loading it first or last.

A start would be for the manual to encourage using a
`custom-file', in its discussion of init files.  And it
wouldn't hurt to include a simple example of defining it
and loading it in an init file.  A user doesn't have to
be an expert in all the intricacies of Customize to learn
how to define and load a `custom-file'.

[There should also perhaps be some mention of the possibly
confusing fact that `custom-file' is itself a user option,
i.e., something managed by Customize!  Clearly it is a
special option, in that you cannot depend on it becoming
properly defined by loading the file that defines it!]

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On 8 Nov 2015 3:26 am, "David Reitter" <david.reitter@gmail.com> wrote:
> >
> > Exactly.  So, for these reasons, "the solution" is to add
> > "(package-initialize)" in the ~/.emacs file.
>
> See also Bug#21858.
>
> Adding (package-initialize) to a user-controlled file is ugly if it has
the consequence that it breaks startup of any older Emacs on the system.
> Also, note that the action is not undoable from the menus, even though
installing a package can be done via the menu.

Alternatives to this have been discussed here before, but haven't been done
simply because nobody did them. I can dig up the conversations if you'd
like.

Like I've said. I'm not thrilled about changing the file, but I still
consider that better than the alternative.

[-- Attachment #2: Type: text/html, Size: 974 bytes --]

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

On 8 Nov 2015 10:48 am, "Artur Malabarba" <bruce.connor.am@gmail.com> wrote:
> Like I've said. I'm not thrilled about changing the file, but I still
consider that better than the alternative.

Sorry for the confusion. Here I meant "I consider that better than not
doing anything".

[-- Attachment #2: Type: text/html, Size: 407 bytes --]

Re: Customizable modes and package.el

[Achim Gratz]

Artur Malabarba writes:
> If that's the path we're taking, I'd rather simply have
> package-initialize be called before loading the init file, instead of
> after.

You can't do that, it breaks things when you need to set variables
before the packages get initialized.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Customizable modes and package.el

[Ted Zlatanov]

On Mon, 30 Mar 2015 19:45:18 +0200 Achim Gratz <Stromeko@nexgo.de> wrote: 

AG> Artur Malabarba writes:
>> If that's the path we're taking, I'd rather simply have
>> package-initialize be called before loading the init file, instead of
>> after.

AG> You can't do that, it breaks things when you need to set variables
AG> before the packages get initialized.

Can you be more specific about when that may happen?  What variables
need to be set before calling `package-initialize'?  Perhaps these cases
can be handled in clever ways if they only affect a minority?  I don't
know, so please explain gently :)

Thanks
Ted

Re: Customizable modes and package.el

[Stefan Monnier]

> Can you be more specific about when that may happen?  What variables
> need to be set before calling `package-initialize'?  Perhaps these cases
> can be handled in clever ways if they only affect a minority?  I don't
> know, so please explain gently :)

The following vars affect package-initialize and hence need to be set
before package-initialize is run:
- package-directory-list
- package-pinned-packages
- package-load-list

There might be others, but these seem like the most important ones.


        Stefan

Re: Customizable modes and package.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

> AG> You can't do that, it breaks things when you need to set variables
> AG> before the packages get initialized.
>
> Can you be more specific about when that may happen?  What variables
> need to be set before calling `package-initialize'?  Perhaps these cases
> can be handled in clever ways if they only affect a minority?  I don't
> know, so please explain gently :)

You may also be interested in a spin-off thread, "Calling
package-initialize sooner during initialization", where one such clever way
is currently being discussed.

[-- Attachment #2: Type: text/html, Size: 655 bytes --]

Re: Customizable modes and package.el

[Artur Malabarba]

Ok, since I've split the other discussion into its own thread and I
don't know how that's going to take, I'd like to finish this line of
thought.

>> The only thing I'm totally sure on is the `now' parameter. I think
>> it's not a problem, because it's meant to indicate "set the value
>> wihout waiting for the defcustom" and not "set the value immediately",
>> but I don't know its real use-case, so it's hard to say for sure.
>
> Hmm... I thought the idea was to add "(package-initialize)" to the
> ~/.emacs

What did you mean by this, Stefan? Do you think custom.el should add
"(package-initialize)" above the "(custom-set-variables" call?

Re: Customizable modes and package.el

[Stefan Monnier]

>> Hmm... I thought the idea was to add "(package-initialize)" to the
>> ~/.emacs
> What did you mean by this, Stefan? Do you think custom.el should add
> "(package-initialize)" above the "(custom-set-variables" call?

Something like that, yes,


        Stefan

Re: Customizable modes and package.el

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Hmm... I thought the idea was to add "(package-initialize)" to the
>>> ~/.emacs
>> What did you mean by this, Stefan? Do you think custom.el should add
>> "(package-initialize)" above the "(custom-set-variables" call?
>
> Something like that, yes,

I didn't follow the whole discussion, so this is probably naive, but why
doesn't `custom-set-variables` do it as a side-effect then, possible
conditional on some heuristic? I.e. why add another magic form?

João

Re: Customizable modes and package.el

[Richard Y. Kim]

I have been a long time emacs user, but I just joined emacs-devel list
for the first time (I think).

I wanted to respond to Stefan's email so I cut-and-pasted his comments
from
<http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00864.html>
in order to respond.

> The following vars affect package-initialize and hence need to be set
> before package-initialize is run:
> - package-directory-list
> - package-pinned-packages
> - package-load-list
> 
> There might be others, but these seem like the most important ones.

I would add `package-user-dir' to Stefan's list which to me is the all
important one since it specifies the location of the installed packages.
I set it to either ~/elisp/24.5.50 or ~/elisp/25.0.50 (kind of confusing
due to too many 5's) depending on the value of `emacs-version'.

Isn't it dangerous to load files byte-compiled by one version of emacs
by another version of emacs due to potential incompatibilities caused by
change in byte-compile formats?  I was burned couple of times over the
years due to change in byte-compile file format.

I have *never* gotten used to using ~/.emacs.d for any purpose.  So the
thought of emacs, by default, using anything in that directory is highly
disturbing to me.  I have always set `user-emacs-directory' to something
like "~/elisp" plus many other variables so that all files generated by
emacs are housed under ~/elisp, not ~/.emacs.d.  Whatever files that may
be under ~/.emacs.d are by accident which resulted from some temporary
experimentation I did via "emacs -q" who knows how many years ago.

If emacs by default starts reading anything under ~/.emacs.d, then I
will probably deal with that by adding code to wipe out ~/.emacs.d
automatically or to do something like "chmod 0 ~/.emacs.d" to make it
not readable.