I'm unsure which option to use for setting a variable: setq, customize-set-variable, or setopt

Question

I'm a bit uncertain about which method to use for setting a variable: setq, customize-set-variable, or setopt. I did some research online, and it seems that opinions on this matter are quite varied. Here are the options I'm considering:

1. Just use setq without overthinking it.

2. Follow the suggestion from this website and use customize-set-variable when possible. https://macowners.club/posts/setq-vs-customize-set-variable/

3. Use the use-package macro for configuring variables in the :custom section. Now use-package is part of Emacs core and I'm already using it for about 90% of my config.

These are the settings I want to review:

(setq-default
 inhibit-startup-screen t             ; Disable the startup screen
 initial-scratch-message nil          ; Empty the initial *scratch* buffer
 indent-tabs-mode nil                 ; Insert space characters instead of tabs
 tab-width 2                          ; The number of spaces a tab is equal to
 fill-column 78                       ; Line length above which to break a line
 cursor-type 'bar                     ; Display the cursor as a vertical bar)

Let's take the first one:

(setq inhibit-startup-screen t)

When I check how it looks with M-x customize-option inhibit-startup-screen the GUI interface says: CHANGED outside Customize.

(setopt inhibit-startup-screen t)

With setopt, the same message: CHANGED outside Customize.

(customize-set-variable 'inhibit-startup-screen t)

On the other hand customize-set-variable shows: SET for current session only, which according to the website I linked earlier might be the proper way of setting this variable? It's actually interesting that setopt doesn't produce similar results, as it appears to have been added for user customizations according to what I read. Another possibility is that the message "SET for current session only" might not really matter?

If I go with "use-package," I think it'd be more elegant to customize all of these using the "emacs" package, right?

(use-package emacs
  :ensure nil <-- configure a built-in package
  :custom
  ..
  .. move the variables here
  ..
  ..)

When I check how it looks with M-x customize-option inhibit-startup-screen when using use-package to customize, the GUI interface says: THEMED.

Answer 1

Think of the new (Emacs 29+) setopt macro as being a version of setq-default¹ for use with user options².

Specifically, it accepts arguments in the exact same manner as setq-default (and setq) -- which is not true of customize-set-variable which otherwise does the same job -- so you do not need to quote the option symbol when you use setopt, and you can set an arbitrary number of option/value pairs with a single call.

Like customize-set-variable, the code it winds up running to set the value is:

(funcall (or (get variable 'custom-set) #'set-default) variable value)

So if the definition of the user option includes a custom setter function (declared with the :set keyword), that setter will be used; otherwise set-default is called.

(The possibility of such setter functions is the major reason why it can be risky to use setq or setq-default with user options.)

In summary, if you are using Emacs 29+ and do not wish to use the Customize UI then it makes good sense to use:

• setopt for user options
• setq-default for other variables³

I'm not familiar with use-package so I can't confirm how that handles these things.

---

¹ Just like customize-set-variable and the customize UI, setopt sets the default value of the user option rather than any buffer-local value which might exist. It is therefore more like setq-default than setq.

² User options are variables which were defined with defcustom rather than defvar, and they can be set using the Customize UI. Describing them with C-hv will report "You can customize this variable." with a link to do that, and you can also access that UI directly with M-x customize-option.

³ It's fine to use setq in your init file for variables which are not automatically buffer-local (and do not otherwise happen to have a buffer-local value at init time), but if you prefer not to have to think about that then it's also fine to use setq-default regardless.

(Obviously if you intend to set a buffer-local value (perhaps in a particular mode hook), do not use setq-default. In that instance you can use setq-local to be sure of setting the buffer-local value, regardless of whether setq would do that.)