I was experimenting with face definitions and created a number of "test" faces that were meant to be temporary. At the end of the experiments, I wanted to clean up after myself, so I attempted (unintern FACE)
, but the faces remained on the return value of function (face-list)
. My guess was that the faces are stored in a different obarray
. Then I looked at the function definition for (face-list)
in file faces.el
, and it gets its data from variable face-new-frame-defaults
which is defined in C source code
, which is a simple list, and not seemingly updated.
As a complication to testing and debugging, the doc-string for unintern
indicates that FACE can be specified either as a string or as a symbol. However, the function behaves differently for the alternatives. This is kind of a tangent, and may be a bug in unintern
, but it confused debugging my situation. For a normal symbol (setq my-temp-test-symbol "HELP!")
, performing unintern
with a string argument correctly returned t
on symbol-found-and-uninterned and nil
on symbol-not-found; However, when passed a symbol 'my-temp-test-symbol
, it returned t
repeatedly.
For faces, performing unintern
with a symbol argument always returns t
, and with a string argument does first return t
, and then nil
, but the face continues to appear in the output of (face-list)
.
(unintern 'mysym)
always returns t since the reader sees'mysym
interns it and only afterwardsunintern
is called with the (newly interned) symbol as argument. Opposed to that(progn (setq symholder 'mysym) (list (unintern symholder) (unintern symholder)))
returns(t nil)
since the reader does not readmysym
anymore after thesetq
but onlysymholder
. The second example shows that you can pass a symbol without interning it as value of another symbol. See Creating and Interning Symbols.my-temp-test-symbol
then sure, go ahead -- that one is obviously yours to start with -- but in general? Definitely not the way to go.unintern
unless you really know what it does. It's a great footgun, tho.