If the sole purpose of defining my-trash-dir
is to use its value to set the user option trash-directory
, then you should just write
(setq trash-directory (expand-file-name ".trash" user-emacs-directory))
or (if you don't mind wasting a millisecond or two at startup) even
(setq trash-directory (locate-user-emacs-file ".trash"))
This is because trash-directory
is automatically created for you when the command move-file-to-trash
is invoked. Deferring the creation of trash-directory
until it is actually needed will even improve your startup time.
If, however, you want to use my-trash-dir
as a variable for other purposes, there is nothing wrong with using a plain setq
to define it:
(setq my-trash-dir (locate-user-emacs-file ".trash"))
(setq trash-directory my-trash-dir)
(unless (file-exists-p my-trash-dir)
(make-directory my-trash-dir))
There is almost never a need for users to use defconst
, especially given the Emacs philosophy centred around customisability. But there are several advantages to using a defvar
:
(defvar my-trash-dir (locate-user-emacs-file ".trash")
"Personal Emacs trash directory.")
(setq trash-directory my-trash-dir)
(unless (file-exists-p my-trash-dir)
(make-directory my-trash-dir))
You can associate a docstring with it which will be presented by C-hvmy-trash-dir
RET and reduces the need for comments in your code.
Emacs notes the file in which the variable was defined. You can then jump to this location via M-xfind-variable
RET or the hyperlinked button in the *Help*
buffer.
The byte-compiler is made aware of the variable so that it does not complain, should you want to byte-compile your code. The variable also satisfies special-variable-p
, should you ever care about this.
You will be one step closer to achieving Emacs zen[1]. In other words, it is more idiomatic and elegant to define variables prior to their use.
[1]: This claim is provided "as-is", without warranty of any kind.