17

I've accidentally run the following:

(unintern variable)

where variable's value was nil.

How do I get nil back without restarting Emacs?

Malabarba
  • 22,878
  • 6
  • 78
  • 163
Sean Allred
  • 6,861
  • 16
  • 85

1 Answers1

18

(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).

Constantine
  • 9,072
  • 1
  • 34
  • 49
  • Very clever! I agree with `Stef` on this one, actually :) Down that road lies madness. – Sean Allred Oct 31 '14 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? – Gilles 'SO- stop being evil' Oct 31 '14 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 :) – Sean Allred Nov 01 '14 at 00: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 01 '14 at 13:12
  • @Stefan It would seem that's a documentation bug, then :( – Sean Allred Dec 07 '14 at 19:51
  • @SeanAllred: if you think so, then I recommend you `M-x report-emacs-bug` pointing out which part of the doc is misleading and/or explaining what it should say (instead). – Stefan Dec 07 '14 at 20:42
  • @Constantine Can you please fix the link to the specific line in lread.c? As it is linked to the "master" branch, that line reference won't stay constant.. So it would need reference to an absolute commit in this fashion: `http://git.savannah.gnu.org/cgit/emacs.git/tree/src/buffer.c?a=a2981c90f661e8fa0356ee5bfe00f8565d721de8\#n2156` (remove that backslash before #). – Kaushal Modi Jan 21 '16 at 19:53
  • @KaushalModi: Fixed. Thanks for pointing it out! – Constantine Jan 21 '16 at 21:12