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.– MalabarbaCommented Oct 31, 2014 at 23:44
-
@Malabarba :) It was truly a humbling realization when I figured out what I had done– Sean AllredCommented Nov 1, 2014 at 1:23
-
1You can delete nil! Did not see that coming.– GamboCommented Nov 1, 2014 at 6:58
-
@Gambo neither did I :)– Sean AllredCommented Nov 1, 2014 at 13:38
Add a comment
|
1 Answer
(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).
answered Oct 31, 2014 at 23:35
-
Very clever! I agree with
Stefon this one, actually :) Down that road lies madness. Commented Oct 31, 2014 at 23:37 -
Bleh. I agree with rms over sm here. Uninterning
nilis a common error that's easy to protect against. Why put a handrail on a staircase when people could jump over it? Commented 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 :) Commented Nov 1, 2014 at 0:18
-
uninternis not used frequently, really. Using it on the mainobarrayis pretty much always a bad idea (which is why the byte-compiler complains when you fail to pass the second argument, andC-h f uninterndoesn't tell you that the second arg is actually still optional).– StefanCommented Nov 1, 2014 at 13:12 -
@Stefan It would seem that's a documentation bug, then :( Commented Dec 7, 2014 at 19:51