1 files changed, 25 insertions, 0 deletions
diff --git a/devdocs/elisp/eval-during-compile.html b/devdocs/elisp/eval-during-compile.html
new file mode 100644
index 00000000..7257dfa5
--- /dev/null
+++ b/devdocs/elisp/eval-during-compile.html
@@ -0,0 +1,25 @@
+ <h3 class="section">Evaluation During Compilation</h3>  <p>These features permit you to write code to be evaluated during compilation of a program. </p> <dl> <dt id="eval-and-compile">Macro: <strong>eval-and-compile</strong> <em>body…</em>
+</dt> <dd>
+<p>This form marks <var>body</var> to be evaluated both when you compile the containing code and when you run it (whether compiled or not). </p> <p>You can get a similar result by putting <var>body</var> in a separate file and referring to that file with <code>require</code>. That method is preferable when <var>body</var> is large. Effectively <code>require</code> is automatically <code>eval-and-compile</code>, the package is loaded both when compiling and executing. </p> <p><code>autoload</code> is also effectively <code>eval-and-compile</code> too. It’s recognized when compiling, so uses of such a function don’t produce “not known to be defined” warnings. </p> <p>Most uses of <code>eval-and-compile</code> are fairly sophisticated. </p> <p>If a macro has a helper function to build its result, and that macro is used both locally and outside the package, then <code>eval-and-compile</code> should be used to get the helper both when compiling and then later when running. </p> <p>If functions are defined programmatically (with <code>fset</code> say), then <code>eval-and-compile</code> can be used to have that done at compile-time as well as run-time, so calls to those functions are checked (and warnings about “not known to be defined” suppressed). </p>
+</dd>
+</dl> <dl> <dt id="eval-when-compile">Macro: <strong>eval-when-compile</strong> <em>body…</em>
+</dt> <dd>
+<p>This form marks <var>body</var> to be evaluated at compile time but not when the compiled program is loaded. The result of evaluation by the compiler becomes a constant which appears in the compiled program. If you load the source file, rather than compiling it, <var>body</var> is evaluated normally. </p>  <p>If you have a constant that needs some calculation to produce, <code>eval-when-compile</code> can do that at compile-time. For example, </p> <div class="lisp"> <pre class="lisp">(defvar my-regexp
+  (eval-when-compile (regexp-opt '("aaa" "aba" "abb"))))
+</pre>
+</div>  <p>If you’re using another package, but only need macros from it (the byte compiler will expand those), then <code>eval-when-compile</code> can be used to load it for compiling, but not executing. For example, </p> <div class="lisp"> <pre class="lisp">(eval-when-compile
+  (require 'my-macro-package))
+</pre>
+</div> <p>The same sort of thing goes for macros and <code>defsubst</code> functions defined locally and only for use within the file. They are needed for compiling the file, but in most cases they are not needed for execution of the compiled file. For example, </p> <div class="lisp"> <pre class="lisp">(eval-when-compile
+  (unless (fboundp 'some-new-thing)
+    (defmacro 'some-new-thing ()
+      (compatibility code))))
+</pre>
+</div> <p>This is often good for code that’s only a fallback for compatibility with other versions of Emacs. </p> <p><strong>Common Lisp Note:</strong> At top level, <code>eval-when-compile</code> is analogous to the Common Lisp idiom <code>(eval-when (compile eval) …)</code>. Elsewhere, the Common Lisp ‘<samp>#.</samp>’ reader macro (but not when interpreting) is closer to what <code>eval-when-compile</code> does. </p>
+</dd>
+</dl><div class="_attribution">
+  <p class="_attribution-p">
+    Copyright &copy; 1990-1996, 1998-2022 Free Software Foundation, Inc. <br>Licensed under the GNU GPL license.<br>
+    <a href="https://www.gnu.org/software/emacs/manual/html_node/elisp/Eval-During-Compile.html" class="_attribution-link">https://www.gnu.org/software/emacs/manual/html_node/elisp/Eval-During-Compile.html</a>
+  </p>
+</div>