* doc/lispref/macros.texi (Eval During Expansion): Fix fixme

doc/lispref/macros.texi

@@ -480,13 +480,15 @@ in expressions ordinarily.
 
   Another problem can happen if the macro definition itself
 evaluates any of the macro argument expressions, such as by calling
-@code{eval} (@pxref{Eval}).  If the argument is supposed to refer to the
-user's variables, you may have trouble if the user happens to use a
+@code{eval} (@pxref{Eval}).  You have to take into account that the
+context of the caller is not accessible at that time since the macro expansion
+may take place long before the code is executed.  Also if your macro definition
+does not use @code{lexical-binding} its own variables may hide the
+user's variables, if the user happens to use a
 variable with the same name as one of the macro arguments.  Inside the
 macro body, the macro argument binding is the most local binding of this
 variable, so any references inside the form being evaluated do refer to
 it.  Here is an example:
-@c FIXME with lexical-binding t this example no longer applies
 @example
 @group
 (defmacro foo (a)
@@ -508,12 +510,10 @@ it.  Here is an example:
 @code{x}, because @code{a} conflicts with the macro argument variable
 @code{a}.
 
-  Another problem with calling @code{eval} in a macro definition is that
-it probably won't do what you intend in a compiled program.  The
-byte compiler runs macro definitions while compiling the program, when
-the program's own computations (which you might have wished to access
-with @code{eval}) don't occur and its local variable bindings don't
-exist.
+  Also the expansion of @code{(foo x)} above will return something
+different or signal an error when the code is compiled since in that case
+@code{(foo x)} is expanded during compilation whereas the execution of
+@code{(setq x 'b)} will only take place later when the code is executed.
 
   To avoid these problems, @strong{don't evaluate an argument expression
 while computing the macro expansion}.  Instead, substitute the