[Feature]: Better support for custom.el

[darkfeline]

Feature Description

This is more of a wishlist feature and arguably because custom.el is silly.

custom.el is the official method for configuring package user options, enabling global minor modes, etc.

Ideally, customizations need to be loaded after all packages are loaded for everything to apply cleanly. Since elpaca initializes packages asynchronously, we need to do:

(add-hook 'elpaca-after-init-hook (lambda () (load custom-file)))

This isn't the biggest issue, but some customizations like theming are best loaded ASAP, so you would end up loading them again:

(load custom-file)
;; We have to load them again because elpaca activates packages asynchronously.
(add-hook 'elpaca-after-init-hook (lambda () (load custom-file)))

This is fine although a little hacky. Ideally we could have per-package customizations which are loaded as each package is installed or something.

Not sure if you want to do any work here or track this. Perhaps you could just add a note to the documentation and close this as wontfix.

Confirmation

• [X] The feature I'm proposing does not already exist in Elpaca

[progfolio]

some customizations like theming are best loaded ASAP

These types of customizations are best suited for early-init.el (before the first frame is created), which custom.el doesn't account for either.

Ideally, customizations need to be loaded after all packages are loaded for everything to apply cleanly.

Are you sure of this? I don't use custom.el, so I'm not overly familiar with its internals. However, it looks like it uses functions like customize-set-variables, which has the following docstring:

"Install user customizations of variable values specified in ARGS.
These settings are registered as theme ‘user’.
The arguments should each be a list of the form:

  (SYMBOL EXP [NOW [REQUEST [COMMENT]]])

This stores EXP (without evaluating it) as the saved value for SYMBOL.
If NOW is present and non-nil, then also evaluate EXP and set
the default value for the SYMBOL to the value of EXP.

REQUEST is a list of features we must require in order to
handle SYMBOL properly.
COMMENT is a comment string about SYMBOL.

(fn &rest ARGS)"

That sounds like evaluating the customization form would only set the saved value for each option. Are there specific cases you know of that will fail if the file isn't loaded after all packages are loaded? Wouldn't any autoloaded package suffer from the same problem?

[darkfeline]

No, customizations have side effects (:set in defcustom). Global minor modes are an easy example, if you set and save them via custom.el. If you load the customizations before activating the package (loading autoloads; customizations get a special autoload form), it won't activate properly.

[progfolio]

I see. Thanks for the example. I've added a mention to the docs:

https://github.com/progfolio/elpaca/commit/e19a8e851243dd7d04275c658b77c98e995349bf

Ideally we could have per-package customizations which are loaded as each package is installed or something.

This sounds like use-package's :config keyword to me. So I would recommend something similar to that. I don't think there's much else I can do on Elpaca's side (without re-inventing custom.el). If you get any ideas for alternative solutions, let me know.

[meedstrom]

Ideally we could have per-package customizations which are loaded as each package is installed or something.

Well, if you wanted to be declarative, there is use-package :custom or just writing (setopt VAR VAL) in :config:.

But for me the point of custom.el is a minority of variables which are better not to manage declaratively. Examples:

• org-agenda-files -- It's nice if I can just use the command org-agenda-file-to-front (C-c [) and have the file remembered for future sessions.
• org-capture-templates -- much more newbie-friendly to edit in the Custom UI
• Enabling each disabled command as I encounter them -- should not also have to write (put 'command 'disabled nil) into initfiles manually
• Back when I used org-drill, it saved difficulty matrices for each flashcard using custom-set. Probably the wrong way to go about it, but packages like that exist.

On that topic, though I do set custom-file to a path, nothing is being written into the file... Bug or just me?

[progfolio]

On that topic, though I do set custom-file to a path, nothing is being written into the file... Bug or just me?

I doubt this is related to Elpaca. If you can reproduce the issue in a way that shows it is, I'd be happy to look into it. I'd ask for support on a more general Emacs forum first, though.