summaryrefslogtreecommitdiff
path: root/lisp/textmodes/string-edit.el
diff options
context:
space:
mode:
authorStefan Monnier <monnier@iro.umontreal.ca>2022-05-25 17:53:39 -0400
committerStefan Monnier <monnier@iro.umontreal.ca>2022-05-26 12:21:32 -0400
commit80ba4c170756049a101b4e6692882ac30ba5e1a5 (patch)
tree6dd293220256c8ce06e474c9457a4e448f7dd7ee /lisp/textmodes/string-edit.el
parent77b5840d4ab37c1485745def5ec0c9b9f6cb137f (diff)
downloademacs-80ba4c170756049a101b4e6692882ac30ba5e1a5.tar.gz
emacs-80ba4c170756049a101b4e6692882ac30ba5e1a5.tar.bz2
emacs-80ba4c170756049a101b4e6692882ac30ba5e1a5.zip
eval.c: New functions `defvar-1` and `defconst-1` (bug#55156)
The bytecode interpreter can't directly call special forms, so the byte-compiler usually converts special forms into some sequence of byte codes (basically, providing a duplicate definition of the special form). There are still two exceptions to this: `defconst` and `defvar`, where the compiler instead generates a convoluted chunk of code like: (funcall '(lambda (x) (defvar <sym> x <doc>)) <value>) where the quote makes sure we keep the function non-compiled, so as to end up running the special form at run time. Get rid of this workaround by introducing `defvar-1` and `defconst-1` which provide a *functional* interface to the functionality of the corresponding special form. * src/eval.c (defvar, Fdefvar_1, Fdefconst_1): New functions, extracted from `Fdefvar` and `Fdefconst`. (Fdefvar, Fdefconst): Use them. (syms_of_eval): `defsubr` the new functions. * lisp/emacs-lisp/bytecomp.el (byte-compile-tmp-var): Delete const. (byte-compile-defvar): Simplify using the new functions. * doc/lispref/variables.texi (Defining Variables): Adjust the doc of `defvar` to reflect the actual semantics implemented.
Diffstat (limited to 'lisp/textmodes/string-edit.el')
0 files changed, 0 insertions, 0 deletions