For example, lets say a package defines a variable foo: (A B C), but through customize, I remove C from the list. Now the variable foo is (A B). What happens if later, the package maintainers change the variable foo so that it is now (A B C D). Will my setting in customize continue to be respected? If so, how will I ever no that this list now includes more members?

If that was a little too unclear, here is the actual use case: I have removed elpy-module-yasnippet from the list elpy-modules as suggested in the comments to this question. Since the list of modules is now explicitly defined in my customizations file, does this mean that if elpy someday adds new and exciting modules, by default I will not have them?

  • 1
    Yes. It's a feature. Your customized value always takes precedence. Unfortunately, that means that you are not informed of changes in the default. That's particularly problematic if the :type of the value changes.
    – Drew
    Mar 21 '16 at 22:38
  • 1
    At least for packages distributed with Emacs itself you can find out which options changed since the last release: M-x customize-changed. It shows you all options "whose meanings have changed in Emacs itself". If you give it a version argument, it finds all options changed since that Emacs version.
    – Drew
    Mar 21 '16 at 22:41
  • @Drew thanks for the useful information. I never knew about cystomize-changed! At least for my case it seems like the solution suggested in the accepted answer does the trick pretty well without the side effects I was worried about. It is unfortunate that if you customize a variable like elpy-modules through the customize interface, and uncheck an item, it sets the variable to a list containing all checked items instead of removing the unchecked ones, but I am sure there is a reason for this, and I would rather set it in my init anyway
    – elethan
    Mar 21 '16 at 23:03

The answer to your question is: Yes, you won't hear about the new and exciting modules. But you can write:

(setq foo (remq 'c foo))

to remove c from foo. Or clone the repository and use standard version control tools for making any changes to the source you want.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.