Custom file

[systemcrafters]

Custom file

[astoff]

The result was (push 'narrow-to-region 'disabled nil) inserted in the .emacs file, not the custom.el file.

I guess you mean put, not push. The disabled command feature is governed by symbol properties, so it's a bit of an exception. Let's not discuss those.

warning-suppress-types and safe-local-variable-values are both defcustom values which can be set using customize-set-variable in your configuration. org-agenda-files is a defcustom variable that can be set using customize-set-variable as well, still without needing to actually load the custom-file.

That's right. Let's take org-agenda-files as an example. You can setq it to some value in your init file and commit that under your version controlled configuration. Same agenda files “forever” and on every machine you use. That's alright.

But other workflows are possible. Maybe you don't want to sync agenda files across all your computers. Or maybe instead of a few big agenda files that never change, one may use smaller files (say one per project) that change all the time or depend on the machine. So you don't want to version control that list. Instead, you will use M-x org-agenda-file-to-front and M-x org-remove-file to manage the list of agenda files. If you do that and don't load the custom file, your changes will not persist.

I am happy to do further research on this, would you be able to provide use-cases for the list you provide in this issue with detailed examples (ideally the steps you take to set each) of how you are setting those values?

I think the best example are dir-local variables. You know what I mean, right? Just create a dir-locals.el in some directory and add some variable that is not ”safe as a file-local variable”. For instance comment-fill-column or the executable name of some interpreter or other program. You will be asked if you want to apply the variable and whether to mark it as safe:

Do you want to apply it?  You can type
y  -- to apply the local variables list.
n  -- to ignore the local variables list.
!  -- to apply the local variables list, and permanently mark these
      values (*) as safe (in the future, they will be set automatically.)
i  -- to ignore the local variables list, and permanently mark these
      values (*) as ignored

If you don't load the custom file, the ! will just not work. My current custom value of safe-local-variable-values has a lot of garbage that I accepted while working on my current laptop, and I don't want to commit all that garbage to version control. If I move the a new machine, I'll just accept again the values as I get asked.

So, in short: I think it's not a good practice to not load the custom file when it exists. Some packages and built-in features use it to persist data.

[astoff]

All right, the Readme explanation looks good to me, the code too. (I guess I'd simply load the custom file at the end of init.el, not in the after-init hook. but I presume you have a reason for doing it the that way). Thanks!

[jeffbowman]

I read through most of the custom.el (and associated cus-*.el files) to track through how customizations are working. It is possible I missed something, but what I understand from that research is what is stated in the README.org for this project.

One thing I was curious about was disabled commands, for example narrow-to-region. I created a simple .emacs file in a virtual machine with only 1 line: (customize-set-variable 'custom-file (expand-file-name "custom.el" (getenv "HOME"))). Then I restarted emacs, selected a region and typed C-x n n which called up the disabled command warning. I pressed y to enable the command and save it for later so I don't get asked about it again. The result was (push 'narrow-to-region 'disabled nil) inserted in the .emacs file, not the custom.el file. Since the initialization file is always loaded, disabled commands, when enabled and persisted, will continue to be enabled without having to load custom.el.

warning-suppress-types and safe-local-variable-values are both defcustom values which can be set using customize-set-variable in your configuration. org-agenda-files is a defcustom variable that can be set using customize-set-variable as well, still without needing to actually load the custom-file.

However, if those are set through the Customization UI, those values are definitely set in the custom-set-variables form and persisted to the custom-file which, if not loaded in your config, would not be set when you start a new Emacs session.

In the end, it really depends on how you set these variables as to whether they are persisted in the custom-file and whether you need to load that file in your config.

I am happy to do further research on this, would you be able to provide use-cases for the list you provide in this issue with detailed examples (ideally the steps you take to set each) of how you are setting those values? If I missed something about how customization works, I definitely want to figure that out and update the README.org so it is accurate.

[jeffbowman]

I guess you mean put, not push. The disabled command feature is governed by symbol properties, so it's a bit of an exception. Let's not discuss those.

d'oh! Yes, I meant put

But other workflows are possible. Maybe you don't want to sync agenda files across all your computers. Or maybe instead of a few big agenda files that never change, one may use smaller files (say one per project) that change all the time or depend on the machine. So you don't want to version control that list. Instead, you will use M-x org-agenda-file-to-front and M-x org-remove-file to manage the list of agenda files. If you do that and don't load the custom file, your changes will not persist.

Interesting, not a workflow I was aware of. I appreciate the description, might even have to try that out. It still seems like you might put "common" directory (ala ~/org) on the org-agenda-files list regardless of what system you happen to be on since all org files in that directory would be added as agenda files... but poping agenda files forward and then later removing them would still be an issue if it is writing to the customization system and eventually persisted to the custom-set-variables form.

I think the best example are dir-local variables. You know what I mean, right? Just create a dir-locals.el in some directory and add some variable that is not ”safe as a file-local variable”. For instance comment-fill-column or the executable name of some interpreter or other program.

Yep, I use dir-local values from time to time, but I just answer 'Y' because I want to be prompted each time so that I look and remember what I had setup. I don't use ! to remember my decision that these are safe from now on, so I never see this in my custom-set-variables form.

So, in short: I think it's not a good practice to not load the custom file when it exists. Some packages and built-in features use it to persist data.

I appreciate your opinion, and the information you have provided here. Naturally I can't predict how any one will use Emacs in their day-to-day activities, and there is no intention to do so anyway. And, of note, Rational Emacs does not keep you from loading the custom-file in your own configuration.

So, not loading it by default is based on a) it duplicates work already done thus wasting time during startup, b) because of (a) you generally don't need to load it, c) its a little risky to load it if duplicate variables exist with different values (last one wins), and d) anyone who needed it could load it when they chose.

We could load the custom-file in the after-init-hook which would at least load it last, but we should also store the values set during the init process so the most current values are in the custom-set-variables before it is loaded from the custom-file. This will, of course, slow down startup times but it may not be noticeable. I'll look into it. Or, if you have a PR... ;-)

[jeffbowman]

Ok, simplicity itself... I'll provide a PR for this in the morning. Took me 5 minutes to code and less time to test. Easy-peasy.

[jeffbowman]

@astoff I have submitted a PR, I'd appreciate your feedback.

[jeffbowman]

It's so they can remove the hook and not load the custom.el file in their configuration if they choose. With that intention, I realized I needed to move whole bit of custom-file stuff above the call to load the user's config.el file.