How do you "redeclare" a variable to avoid flycheck error messages?

`org-structure-template-alist` is declared as `defcustom` in org.el, but I have set it in a different file and flycheck highlights it with the message "assignment to free variable 'org-structure-template-alist'". Do I need to "include" org.el in the file to avoid that warning?

If it's declared with defcustom, you should just be able to use customize to set it; this should avoid any confusion.

`Customize` is not amenable to proper source code control. Have you seen the diffs customize creates?

customize-set-variable

I have—I've kept my .emacs in source control since 2001. Customize keeps itself sorted with one setting per line. It's about as amenable to source code control as you can get…

I discus this a little here: https://macowners.club/posts/setq-vs-customize-set-variable/ In this case you do not need to include you custom file in the source control.

I suggest you look at the diffs that come from installing new packages as an example.

What diffs are you referring to?

To answer your question (though the meta-answer, that you should use Customize, is better advice): yes, you can `(require 'org)`. That should eliminate the warning.

When the diffs of the `custom.el` are virtually unreadable. The diffs of the files where you set the values in code are easier to read.

I don't think you're correct, and I'm a little surprised at how categorically certain you seem to be. Like @__david__ I've had my config under SCM for at least 15 years. I will make this claim and challenge you to refute it: there is in fact *no* easier-to-read diff of a user option setting than the diff of a declarative (that is, Customize) user option setting, and certainly not an imperative (that is, init file elisp code) one. I have what I believe is an example that shows that your claim is empirically false, from just a few days ago. I had quit Emacs having executed `toggle-debug-on-quit` on, without remembering to turn it back off before quitting. I had also updated some other user option. The user option `debug-on-quit` was persisted to my custom file. This meant that `debug-on-quit` was on from startup onward, with the outcome that the first time I hit `C-g` after startup I found myself in the debugger. The cause was immediately obvious from a diff of my custom file and the problem was then trivially easy to resolve. As to new packages, simply installing a new package will not (usually? I can't think of any exceptions) cause any new customize settings to apear in your custom file. That only happens after you load the package and choose to change one or more of its user options. So I'm again surprised at your mention of "diffs that come from installing new packages". I asked you before what diffs you were referring to. Please provide at least one example.

I manage my configuration with `use-package` and I prefer to use the `:custom` keyword to customise the settings. If I make changes to the `:custom` values I find those easier to track than when I change those settings in the customize interface. Some values are automatically set in the `custom.el` file as you go about your editing, and I agree that those diffs are useful, but for values I set deliberately I prefer to set those in code rather than the custom interface. I can create an issue for the change I want to make, update my `init.el` and commit it knowing exactly what I changed. Some of these changes also update `custom.el` I'm sure you have used tools which use dialogs to configure the settings which are then saved to XML, yaml or some other configuration format, and when you have seen how difficult they can be to manage, you learn to value Emacs ability to allow you set everything you want in your `init.el` files, the customize interface notwithstanding.

So you also use a declarative form, not an imperative one, just distributed throughout your various `use-package` declarations rather than in one place via your custom file. Nothing wrong with that, but hardly visibly different in terms of diffs, surely! That seems to me to be quite a different thing from setting them "in code", which is what you said you were doing, and which (to me at least, and I suspect to any programmer with extensive experience), means an imperative approach (at least in the context of Emacs config). OP's imperative approach is what we're discussing in this thread, after all! BTW, I not only use `use-package`, I've contributed code to it several times. I don't use its `:custom` facility though, since I find the `initsplit` package gives me substantially more flexibility, which is particularly useful for partitioning user options per-host, per-OS, and per-display-keyboard-mouse-config.

https://emacs.stackexchange.com/a/106/105