diff --git a/doc/master/dangling_lfun_closure b/doc/master/dangling_lfun_closure
index 6bfaeb5..0bd881f 100644
--- a/doc/master/dangling_lfun_closure
+++ b/doc/master/dangling_lfun_closure
@@ -1,26 +1,30 @@
 SYNOPSIS
-	void dangling_lfun_closure()
+        void dangling_lfun_closure()
 
 DESCRIPTION
-	Handle a dangling lfun-closure.
+        Handle a dangling lfun-closure.
 
-	This is called when the gamedriver executes a closure using a
-	vanished lfun. A proper handling is to raise a runtime error.
+        This is called when the gamedriver executes a closure using a
+        vanished lfun, with previous_object() showing the originating
+        object. A proper handling is to raise a runtime error.
 
-	Technical:
-	  Upon replacing programs (see efun replace_program()), any
-	  existing lambda closures of the object are adjusted to the
-	  new environment. If a closure uses a lfun which vanished in
-	  the replacement process, the reference to this lfun is
-	  replaced by a reference to this function. The error will
-	  then occur when the execution of the adjusted lambda reaches
-	  the point of the lfun reference. There are two reasons for
-	  the delayed handling. First is that the program replacement
-	  and with it the closure adjustment happens at the end of a
-	  backend cycle, outside of any execution thread: noone would
-	  see the error at this time.  Second, smart closures might
-	  know/recognize the program replacement  and skip the call to
-	  the vanished lfun.
+        Technical:
+          Upon replacing programs (see efun replace_program()), any
+          existing lambda closures of the object are adjusted to the
+          new environment. If a closure uses a lfun which vanished in
+          the replacement process, the reference to the lfun is
+          replaced by an alien-lfun closure referencing to this function.
+          The error will then occur when the execution of the adjusted lambda
+          reaches the point of the lfun reference. There are two reasons for
+          the delayed handling. First is that the program replacement and with
+          it the closure adjustment happens at the end of a backend cycle,
+          outside of any execution thread: noone would see the error at this
+          time. Second, smart closures might know/recognize the program
+          replacement and skip the call to the vanished lfun.
+
+HISTORY
+        Since LDMud 3.2.9, all references to dangling_lfun_closure() are
+        created as alien-lfun closures.
 
 SEE ALSO
-	closures(LPC)
+        closures(LPC)