I've accidentally run the following:

(unintern variable)

where variable's value was nil.

How do I get nil back without restarting Emacs?

  • 3
    +1 for making me chuckle. :-) Not in a condescending way, but in a "I would have totally done that as well" way.
    – Malabarba
    Oct 31, 2014 at 23:44
  • @Malabarba :) It was truly a humbling realization when I figured out what I had done Nov 1, 2014 at 1:23
  • 1
    You can delete nil! Did not see that coming.
    – Gambo
    Nov 1, 2014 at 6:58
  • @Gambo neither did I :) Nov 1, 2014 at 13:38

1 Answer 1


(defconst nil ())

seems to have the right effect; note that nil and an empty list are indistinguishable in Emacs Lisp.

I looked at lread.c:4034 to see how nil is created in an obarray.

Note the comment at line 3896 in lread.c:

/* There are plenty of other symbols which will screw up the Emacs
     session if we unintern them, as well as even more ways to use
     `setq' or `fset' or whatnot to make the Emacs session
     unusable.  Let's not go down this silly road.  --Stef  */
  /* if (EQ (tem, Qnil) || EQ (tem, Qt))
       error ("Attempt to unintern t or nil"); */

This explains why Emacs does not protect against (unintern nil) and (unintern t).

  • Very clever! I agree with Stef on this one, actually :) Down that road lies madness. Oct 31, 2014 at 23:37
  • Bleh. I agree with rms over sm here. Uninterning nil is a common error that's easy to protect against. Why put a handrail on a staircase when people could jump over it? Oct 31, 2014 at 23:55
  • @Gilles I think about this as I think about C: C maintains the philosophy that the programmer knows what he is doing and merely requires a way to express himself. IMO, we should regard emacs lisp as the assembly language of emacs; higher abstractions (and guards/features) should be added in a language that compiles to elisp. But that is certainly a topic for another medium :) Nov 1, 2014 at 0:18
  • unintern is not used frequently, really. Using it on the main obarray is pretty much always a bad idea (which is why the byte-compiler complains when you fail to pass the second argument, and C-h f unintern doesn't tell you that the second arg is actually still optional).
    – Stefan
    Nov 1, 2014 at 13:12
  • @Stefan It would seem that's a documentation bug, then :( Dec 7, 2014 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.