| 1 | @c -*-texinfo-*- |
| 2 | @c This is part of the GNU Emacs Lisp Reference Manual. |
| 3 | @c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2000, 2002, |
| 4 | @c 2003, 2004, 2005, 2006 Free Software Foundation, Inc. |
| 5 | @c See the file elisp.texi for copying conditions. |
| 6 | @setfilename ../info/variables |
| 7 | @node Variables, Functions, Control Structures, Top |
| 8 | @chapter Variables |
| 9 | @cindex variable |
| 10 | |
| 11 | A @dfn{variable} is a name used in a program to stand for a value. |
| 12 | Nearly all programming languages have variables of some sort. In the |
| 13 | text of a Lisp program, variables are written using the syntax for |
| 14 | symbols. |
| 15 | |
| 16 | In Lisp, unlike most programming languages, programs are represented |
| 17 | primarily as Lisp objects and only secondarily as text. The Lisp |
| 18 | objects used for variables are symbols: the symbol name is the variable |
| 19 | name, and the variable's value is stored in the value cell of the |
| 20 | symbol. The use of a symbol as a variable is independent of its use as |
| 21 | a function name. @xref{Symbol Components}. |
| 22 | |
| 23 | The Lisp objects that constitute a Lisp program determine the textual |
| 24 | form of the program---it is simply the read syntax for those Lisp |
| 25 | objects. This is why, for example, a variable in a textual Lisp program |
| 26 | is written using the read syntax for the symbol that represents the |
| 27 | variable. |
| 28 | |
| 29 | @menu |
| 30 | * Global Variables:: Variable values that exist permanently, everywhere. |
| 31 | * Constant Variables:: Certain "variables" have values that never change. |
| 32 | * Local Variables:: Variable values that exist only temporarily. |
| 33 | * Void Variables:: Symbols that lack values. |
| 34 | * Defining Variables:: A definition says a symbol is used as a variable. |
| 35 | * Tips for Defining:: Things you should think about when you |
| 36 | define a variable. |
| 37 | * Accessing Variables:: Examining values of variables whose names |
| 38 | are known only at run time. |
| 39 | * Setting Variables:: Storing new values in variables. |
| 40 | * Variable Scoping:: How Lisp chooses among local and global values. |
| 41 | * Buffer-Local Variables:: Variable values in effect only in one buffer. |
| 42 | * Frame-Local Variables:: Variable values in effect only in one frame. |
| 43 | * Future Local Variables:: New kinds of local values we might add some day. |
| 44 | * File Local Variables:: Handling local variable lists in files. |
| 45 | * Variable Aliases:: Variables that are aliases for other variables. |
| 46 | * Variables with Restricted Values:: Non-constant variables whose value can |
| 47 | @emph{not} be an arbitrary Lisp object. |
| 48 | @end menu |
| 49 | |
| 50 | @node Global Variables |
| 51 | @section Global Variables |
| 52 | @cindex global variable |
| 53 | |
| 54 | The simplest way to use a variable is @dfn{globally}. This means that |
| 55 | the variable has just one value at a time, and this value is in effect |
| 56 | (at least for the moment) throughout the Lisp system. The value remains |
| 57 | in effect until you specify a new one. When a new value replaces the |
| 58 | old one, no trace of the old value remains in the variable. |
| 59 | |
| 60 | You specify a value for a symbol with @code{setq}. For example, |
| 61 | |
| 62 | @example |
| 63 | (setq x '(a b)) |
| 64 | @end example |
| 65 | |
| 66 | @noindent |
| 67 | gives the variable @code{x} the value @code{(a b)}. Note that |
| 68 | @code{setq} does not evaluate its first argument, the name of the |
| 69 | variable, but it does evaluate the second argument, the new value. |
| 70 | |
| 71 | Once the variable has a value, you can refer to it by using the symbol |
| 72 | by itself as an expression. Thus, |
| 73 | |
| 74 | @example |
| 75 | @group |
| 76 | x @result{} (a b) |
| 77 | @end group |
| 78 | @end example |
| 79 | |
| 80 | @noindent |
| 81 | assuming the @code{setq} form shown above has already been executed. |
| 82 | |
| 83 | If you do set the same variable again, the new value replaces the old |
| 84 | one: |
| 85 | |
| 86 | @example |
| 87 | @group |
| 88 | x |
| 89 | @result{} (a b) |
| 90 | @end group |
| 91 | @group |
| 92 | (setq x 4) |
| 93 | @result{} 4 |
| 94 | @end group |
| 95 | @group |
| 96 | x |
| 97 | @result{} 4 |
| 98 | @end group |
| 99 | @end example |
| 100 | |
| 101 | @node Constant Variables |
| 102 | @section Variables that Never Change |
| 103 | @vindex nil |
| 104 | @vindex t |
| 105 | @kindex setting-constant |
| 106 | @cindex keyword symbol |
| 107 | |
| 108 | In Emacs Lisp, certain symbols normally evaluate to themselves. These |
| 109 | include @code{nil} and @code{t}, as well as any symbol whose name starts |
| 110 | with @samp{:} (these are called @dfn{keywords}). These symbols cannot |
| 111 | be rebound, nor can their values be changed. Any attempt to set or bind |
| 112 | @code{nil} or @code{t} signals a @code{setting-constant} error. The |
| 113 | same is true for a keyword (a symbol whose name starts with @samp{:}), |
| 114 | if it is interned in the standard obarray, except that setting such a |
| 115 | symbol to itself is not an error. |
| 116 | |
| 117 | @example |
| 118 | @group |
| 119 | nil @equiv{} 'nil |
| 120 | @result{} nil |
| 121 | @end group |
| 122 | @group |
| 123 | (setq nil 500) |
| 124 | @error{} Attempt to set constant symbol: nil |
| 125 | @end group |
| 126 | @end example |
| 127 | |
| 128 | @defun keywordp object |
| 129 | @tindex keywordp |
| 130 | function returns @code{t} if @var{object} is a symbol whose name |
| 131 | starts with @samp{:}, interned in the standard obarray, and returns |
| 132 | @code{nil} otherwise. |
| 133 | @end defun |
| 134 | |
| 135 | @node Local Variables |
| 136 | @section Local Variables |
| 137 | @cindex binding local variables |
| 138 | @cindex local variables |
| 139 | @cindex local binding |
| 140 | @cindex global binding |
| 141 | |
| 142 | Global variables have values that last until explicitly superseded |
| 143 | with new values. Sometimes it is useful to create variable values that |
| 144 | exist temporarily---only until a certain part of the program finishes. |
| 145 | These values are called @dfn{local}, and the variables so used are |
| 146 | called @dfn{local variables}. |
| 147 | |
| 148 | For example, when a function is called, its argument variables receive |
| 149 | new local values that last until the function exits. The @code{let} |
| 150 | special form explicitly establishes new local values for specified |
| 151 | variables; these last until exit from the @code{let} form. |
| 152 | |
| 153 | @cindex shadowing of variables |
| 154 | Establishing a local value saves away the previous value (or lack of |
| 155 | one) of the variable. When the life span of the local value is over, |
| 156 | the previous value is restored. In the mean time, we say that the |
| 157 | previous value is @dfn{shadowed} and @dfn{not visible}. Both global and |
| 158 | local values may be shadowed (@pxref{Scope}). |
| 159 | |
| 160 | If you set a variable (such as with @code{setq}) while it is local, |
| 161 | this replaces the local value; it does not alter the global value, or |
| 162 | previous local values, that are shadowed. To model this behavior, we |
| 163 | speak of a @dfn{local binding} of the variable as well as a local value. |
| 164 | |
| 165 | The local binding is a conceptual place that holds a local value. |
| 166 | Entry to a function, or a special form such as @code{let}, creates the |
| 167 | local binding; exit from the function or from the @code{let} removes the |
| 168 | local binding. As long as the local binding lasts, the variable's value |
| 169 | is stored within it. Use of @code{setq} or @code{set} while there is a |
| 170 | local binding stores a different value into the local binding; it does |
| 171 | not create a new binding. |
| 172 | |
| 173 | We also speak of the @dfn{global binding}, which is where |
| 174 | (conceptually) the global value is kept. |
| 175 | |
| 176 | @cindex current binding |
| 177 | A variable can have more than one local binding at a time (for |
| 178 | example, if there are nested @code{let} forms that bind it). In such a |
| 179 | case, the most recently created local binding that still exists is the |
| 180 | @dfn{current binding} of the variable. (This rule is called |
| 181 | @dfn{dynamic scoping}; see @ref{Variable Scoping}.) If there are no |
| 182 | local bindings, the variable's global binding is its current binding. |
| 183 | We sometimes call the current binding the @dfn{most-local existing |
| 184 | binding}, for emphasis. Ordinary evaluation of a symbol always returns |
| 185 | the value of its current binding. |
| 186 | |
| 187 | The special forms @code{let} and @code{let*} exist to create |
| 188 | local bindings. |
| 189 | |
| 190 | @defspec let (bindings@dots{}) forms@dots{} |
| 191 | This special form binds variables according to @var{bindings} and then |
| 192 | evaluates all of the @var{forms} in textual order. The @code{let}-form |
| 193 | returns the value of the last form in @var{forms}. |
| 194 | |
| 195 | Each of the @var{bindings} is either @w{(i) a} symbol, in which case |
| 196 | that symbol is bound to @code{nil}; or @w{(ii) a} list of the form |
| 197 | @code{(@var{symbol} @var{value-form})}, in which case @var{symbol} is |
| 198 | bound to the result of evaluating @var{value-form}. If @var{value-form} |
| 199 | is omitted, @code{nil} is used. |
| 200 | |
| 201 | All of the @var{value-form}s in @var{bindings} are evaluated in the |
| 202 | order they appear and @emph{before} binding any of the symbols to them. |
| 203 | Here is an example of this: @code{z} is bound to the old value of |
| 204 | @code{y}, which is 2, not the new value of @code{y}, which is 1. |
| 205 | |
| 206 | @example |
| 207 | @group |
| 208 | (setq y 2) |
| 209 | @result{} 2 |
| 210 | @end group |
| 211 | @group |
| 212 | (let ((y 1) |
| 213 | (z y)) |
| 214 | (list y z)) |
| 215 | @result{} (1 2) |
| 216 | @end group |
| 217 | @end example |
| 218 | @end defspec |
| 219 | |
| 220 | @defspec let* (bindings@dots{}) forms@dots{} |
| 221 | This special form is like @code{let}, but it binds each variable right |
| 222 | after computing its local value, before computing the local value for |
| 223 | the next variable. Therefore, an expression in @var{bindings} can |
| 224 | reasonably refer to the preceding symbols bound in this @code{let*} |
| 225 | form. Compare the following example with the example above for |
| 226 | @code{let}. |
| 227 | |
| 228 | @example |
| 229 | @group |
| 230 | (setq y 2) |
| 231 | @result{} 2 |
| 232 | @end group |
| 233 | @group |
| 234 | (let* ((y 1) |
| 235 | (z y)) ; @r{Use the just-established value of @code{y}.} |
| 236 | (list y z)) |
| 237 | @result{} (1 1) |
| 238 | @end group |
| 239 | @end example |
| 240 | @end defspec |
| 241 | |
| 242 | Here is a complete list of the other facilities that create local |
| 243 | bindings: |
| 244 | |
| 245 | @itemize @bullet |
| 246 | @item |
| 247 | Function calls (@pxref{Functions}). |
| 248 | |
| 249 | @item |
| 250 | Macro calls (@pxref{Macros}). |
| 251 | |
| 252 | @item |
| 253 | @code{condition-case} (@pxref{Errors}). |
| 254 | @end itemize |
| 255 | |
| 256 | Variables can also have buffer-local bindings (@pxref{Buffer-Local |
| 257 | Variables}) and frame-local bindings (@pxref{Frame-Local Variables}); a |
| 258 | few variables have terminal-local bindings (@pxref{Multiple Displays}). |
| 259 | These kinds of bindings work somewhat like ordinary local bindings, but |
| 260 | they are localized depending on ``where'' you are in Emacs, rather than |
| 261 | localized in time. |
| 262 | |
| 263 | @defvar max-specpdl-size |
| 264 | @anchor{Definition of max-specpdl-size} |
| 265 | @cindex variable limit error |
| 266 | @cindex evaluation error |
| 267 | @cindex infinite recursion |
| 268 | This variable defines the limit on the total number of local variable |
| 269 | bindings and @code{unwind-protect} cleanups (@pxref{Cleanups,, |
| 270 | Cleaning Up from Nonlocal Exits}) that are allowed before signaling an |
| 271 | error (with data @code{"Variable binding depth exceeds |
| 272 | max-specpdl-size"}). |
| 273 | |
| 274 | This limit, with the associated error when it is exceeded, is one way |
| 275 | that Lisp avoids infinite recursion on an ill-defined function. |
| 276 | @code{max-lisp-eval-depth} provides another limit on depth of nesting. |
| 277 | @xref{Definition of max-lisp-eval-depth,, Eval}. |
| 278 | |
| 279 | The default value is 1000. Entry to the Lisp debugger increases the |
| 280 | value, if there is little room left, to make sure the debugger itself |
| 281 | has room to execute. |
| 282 | @end defvar |
| 283 | |
| 284 | @node Void Variables |
| 285 | @section When a Variable is ``Void'' |
| 286 | @kindex void-variable |
| 287 | @cindex void variable |
| 288 | |
| 289 | If you have never given a symbol any value as a global variable, we |
| 290 | say that that symbol's global value is @dfn{void}. In other words, the |
| 291 | symbol's value cell does not have any Lisp object in it. If you try to |
| 292 | evaluate the symbol, you get a @code{void-variable} error rather than |
| 293 | a value. |
| 294 | |
| 295 | Note that a value of @code{nil} is not the same as void. The symbol |
| 296 | @code{nil} is a Lisp object and can be the value of a variable just as any |
| 297 | other object can be; but it is @emph{a value}. A void variable does not |
| 298 | have any value. |
| 299 | |
| 300 | After you have given a variable a value, you can make it void once more |
| 301 | using @code{makunbound}. |
| 302 | |
| 303 | @defun makunbound symbol |
| 304 | This function makes the current variable binding of @var{symbol} void. |
| 305 | Subsequent attempts to use this symbol's value as a variable will signal |
| 306 | the error @code{void-variable}, unless and until you set it again. |
| 307 | |
| 308 | @code{makunbound} returns @var{symbol}. |
| 309 | |
| 310 | @example |
| 311 | @group |
| 312 | (makunbound 'x) ; @r{Make the global value of @code{x} void.} |
| 313 | @result{} x |
| 314 | @end group |
| 315 | @group |
| 316 | x |
| 317 | @error{} Symbol's value as variable is void: x |
| 318 | @end group |
| 319 | @end example |
| 320 | |
| 321 | If @var{symbol} is locally bound, @code{makunbound} affects the most |
| 322 | local existing binding. This is the only way a symbol can have a void |
| 323 | local binding, since all the constructs that create local bindings |
| 324 | create them with values. In this case, the voidness lasts at most as |
| 325 | long as the binding does; when the binding is removed due to exit from |
| 326 | the construct that made it, the previous local or global binding is |
| 327 | reexposed as usual, and the variable is no longer void unless the newly |
| 328 | reexposed binding was void all along. |
| 329 | |
| 330 | @smallexample |
| 331 | @group |
| 332 | (setq x 1) ; @r{Put a value in the global binding.} |
| 333 | @result{} 1 |
| 334 | (let ((x 2)) ; @r{Locally bind it.} |
| 335 | (makunbound 'x) ; @r{Void the local binding.} |
| 336 | x) |
| 337 | @error{} Symbol's value as variable is void: x |
| 338 | @end group |
| 339 | @group |
| 340 | x ; @r{The global binding is unchanged.} |
| 341 | @result{} 1 |
| 342 | |
| 343 | (let ((x 2)) ; @r{Locally bind it.} |
| 344 | (let ((x 3)) ; @r{And again.} |
| 345 | (makunbound 'x) ; @r{Void the innermost-local binding.} |
| 346 | x)) ; @r{And refer: it's void.} |
| 347 | @error{} Symbol's value as variable is void: x |
| 348 | @end group |
| 349 | |
| 350 | @group |
| 351 | (let ((x 2)) |
| 352 | (let ((x 3)) |
| 353 | (makunbound 'x)) ; @r{Void inner binding, then remove it.} |
| 354 | x) ; @r{Now outer @code{let} binding is visible.} |
| 355 | @result{} 2 |
| 356 | @end group |
| 357 | @end smallexample |
| 358 | @end defun |
| 359 | |
| 360 | A variable that has been made void with @code{makunbound} is |
| 361 | indistinguishable from one that has never received a value and has |
| 362 | always been void. |
| 363 | |
| 364 | You can use the function @code{boundp} to test whether a variable is |
| 365 | currently void. |
| 366 | |
| 367 | @defun boundp variable |
| 368 | @code{boundp} returns @code{t} if @var{variable} (a symbol) is not void; |
| 369 | more precisely, if its current binding is not void. It returns |
| 370 | @code{nil} otherwise. |
| 371 | |
| 372 | @smallexample |
| 373 | @group |
| 374 | (boundp 'abracadabra) ; @r{Starts out void.} |
| 375 | @result{} nil |
| 376 | @end group |
| 377 | @group |
| 378 | (let ((abracadabra 5)) ; @r{Locally bind it.} |
| 379 | (boundp 'abracadabra)) |
| 380 | @result{} t |
| 381 | @end group |
| 382 | @group |
| 383 | (boundp 'abracadabra) ; @r{Still globally void.} |
| 384 | @result{} nil |
| 385 | @end group |
| 386 | @group |
| 387 | (setq abracadabra 5) ; @r{Make it globally nonvoid.} |
| 388 | @result{} 5 |
| 389 | @end group |
| 390 | @group |
| 391 | (boundp 'abracadabra) |
| 392 | @result{} t |
| 393 | @end group |
| 394 | @end smallexample |
| 395 | @end defun |
| 396 | |
| 397 | @node Defining Variables |
| 398 | @section Defining Global Variables |
| 399 | @cindex variable definition |
| 400 | |
| 401 | You may announce your intention to use a symbol as a global variable |
| 402 | with a @dfn{variable definition}: a special form, either @code{defconst} |
| 403 | or @code{defvar}. |
| 404 | |
| 405 | In Emacs Lisp, definitions serve three purposes. First, they inform |
| 406 | people who read the code that certain symbols are @emph{intended} to be |
| 407 | used a certain way (as variables). Second, they inform the Lisp system |
| 408 | of these things, supplying a value and documentation. Third, they |
| 409 | provide information to utilities such as @code{etags} and |
| 410 | @code{make-docfile}, which create data bases of the functions and |
| 411 | variables in a program. |
| 412 | |
| 413 | The difference between @code{defconst} and @code{defvar} is primarily |
| 414 | a matter of intent, serving to inform human readers of whether the value |
| 415 | should ever change. Emacs Lisp does not restrict the ways in which a |
| 416 | variable can be used based on @code{defconst} or @code{defvar} |
| 417 | declarations. However, it does make a difference for initialization: |
| 418 | @code{defconst} unconditionally initializes the variable, while |
| 419 | @code{defvar} initializes it only if it is void. |
| 420 | |
| 421 | @ignore |
| 422 | One would expect user option variables to be defined with |
| 423 | @code{defconst}, since programs do not change them. Unfortunately, this |
| 424 | has bad results if the definition is in a library that is not preloaded: |
| 425 | @code{defconst} would override any prior value when the library is |
| 426 | loaded. Users would like to be able to set user options in their init |
| 427 | files, and override the default values given in the definitions. For |
| 428 | this reason, user options must be defined with @code{defvar}. |
| 429 | @end ignore |
| 430 | |
| 431 | @defspec defvar symbol [value [doc-string]] |
| 432 | This special form defines @var{symbol} as a variable and can also |
| 433 | initialize and document it. The definition informs a person reading |
| 434 | your code that @var{symbol} is used as a variable that might be set or |
| 435 | changed. Note that @var{symbol} is not evaluated; the symbol to be |
| 436 | defined must appear explicitly in the @code{defvar}. |
| 437 | |
| 438 | If @var{symbol} is void and @var{value} is specified, @code{defvar} |
| 439 | evaluates it and sets @var{symbol} to the result. But if @var{symbol} |
| 440 | already has a value (i.e., it is not void), @var{value} is not even |
| 441 | evaluated, and @var{symbol}'s value remains unchanged. If @var{value} |
| 442 | is omitted, the value of @var{symbol} is not changed in any case. |
| 443 | |
| 444 | If @var{symbol} has a buffer-local binding in the current buffer, |
| 445 | @code{defvar} operates on the default value, which is buffer-independent, |
| 446 | not the current (buffer-local) binding. It sets the default value if |
| 447 | the default value is void. @xref{Buffer-Local Variables}. |
| 448 | |
| 449 | When you evaluate a top-level @code{defvar} form with @kbd{C-M-x} in |
| 450 | Emacs Lisp mode (@code{eval-defun}), a special feature of |
| 451 | @code{eval-defun} arranges to set the variable unconditionally, without |
| 452 | testing whether its value is void. |
| 453 | |
| 454 | If the @var{doc-string} argument appears, it specifies the documentation |
| 455 | for the variable. (This opportunity to specify documentation is one of |
| 456 | the main benefits of defining the variable.) The documentation is |
| 457 | stored in the symbol's @code{variable-documentation} property. The |
| 458 | Emacs help functions (@pxref{Documentation}) look for this property. |
| 459 | |
| 460 | If the variable is a user option that users would want to set |
| 461 | interactively, you should use @samp{*} as the first character of |
| 462 | @var{doc-string}. This lets users set the variable conveniently using |
| 463 | the @code{set-variable} command. Note that you should nearly always |
| 464 | use @code{defcustom} instead of @code{defvar} to define these |
| 465 | variables, so that users can use @kbd{M-x customize} and related |
| 466 | commands to set them. @xref{Customization}. |
| 467 | |
| 468 | Here are some examples. This form defines @code{foo} but does not |
| 469 | initialize it: |
| 470 | |
| 471 | @example |
| 472 | @group |
| 473 | (defvar foo) |
| 474 | @result{} foo |
| 475 | @end group |
| 476 | @end example |
| 477 | |
| 478 | This example initializes the value of @code{bar} to @code{23}, and gives |
| 479 | it a documentation string: |
| 480 | |
| 481 | @example |
| 482 | @group |
| 483 | (defvar bar 23 |
| 484 | "The normal weight of a bar.") |
| 485 | @result{} bar |
| 486 | @end group |
| 487 | @end example |
| 488 | |
| 489 | The following form changes the documentation string for @code{bar}, |
| 490 | making it a user option, but does not change the value, since @code{bar} |
| 491 | already has a value. (The addition @code{(1+ nil)} would get an error |
| 492 | if it were evaluated, but since it is not evaluated, there is no error.) |
| 493 | |
| 494 | @example |
| 495 | @group |
| 496 | (defvar bar (1+ nil) |
| 497 | "*The normal weight of a bar.") |
| 498 | @result{} bar |
| 499 | @end group |
| 500 | @group |
| 501 | bar |
| 502 | @result{} 23 |
| 503 | @end group |
| 504 | @end example |
| 505 | |
| 506 | Here is an equivalent expression for the @code{defvar} special form: |
| 507 | |
| 508 | @example |
| 509 | @group |
| 510 | (defvar @var{symbol} @var{value} @var{doc-string}) |
| 511 | @equiv{} |
| 512 | (progn |
| 513 | (if (not (boundp '@var{symbol})) |
| 514 | (setq @var{symbol} @var{value})) |
| 515 | (if '@var{doc-string} |
| 516 | (put '@var{symbol} 'variable-documentation '@var{doc-string})) |
| 517 | '@var{symbol}) |
| 518 | @end group |
| 519 | @end example |
| 520 | |
| 521 | The @code{defvar} form returns @var{symbol}, but it is normally used |
| 522 | at top level in a file where its value does not matter. |
| 523 | @end defspec |
| 524 | |
| 525 | @defspec defconst symbol value [doc-string] |
| 526 | This special form defines @var{symbol} as a value and initializes it. |
| 527 | It informs a person reading your code that @var{symbol} has a standard |
| 528 | global value, established here, that should not be changed by the user |
| 529 | or by other programs. Note that @var{symbol} is not evaluated; the |
| 530 | symbol to be defined must appear explicitly in the @code{defconst}. |
| 531 | |
| 532 | @code{defconst} always evaluates @var{value}, and sets the value of |
| 533 | @var{symbol} to the result. If @var{symbol} does have a buffer-local |
| 534 | binding in the current buffer, @code{defconst} sets the default value, |
| 535 | not the buffer-local value. (But you should not be making |
| 536 | buffer-local bindings for a symbol that is defined with |
| 537 | @code{defconst}.) |
| 538 | |
| 539 | Here, @code{pi} is a constant that presumably ought not to be changed |
| 540 | by anyone (attempts by the Indiana State Legislature notwithstanding). |
| 541 | As the second form illustrates, however, this is only advisory. |
| 542 | |
| 543 | @example |
| 544 | @group |
| 545 | (defconst pi 3.1415 "Pi to five places.") |
| 546 | @result{} pi |
| 547 | @end group |
| 548 | @group |
| 549 | (setq pi 3) |
| 550 | @result{} pi |
| 551 | @end group |
| 552 | @group |
| 553 | pi |
| 554 | @result{} 3 |
| 555 | @end group |
| 556 | @end example |
| 557 | @end defspec |
| 558 | |
| 559 | @defun user-variable-p variable |
| 560 | @cindex user option |
| 561 | This function returns @code{t} if @var{variable} is a user option---a |
| 562 | variable intended to be set by the user for customization---and |
| 563 | @code{nil} otherwise. (Variables other than user options exist for the |
| 564 | internal purposes of Lisp programs, and users need not know about them.) |
| 565 | |
| 566 | User option variables are distinguished from other variables either |
| 567 | though being declared using @code{defcustom}@footnote{They may also be |
| 568 | declared equivalently in @file{cus-start.el}.} or by the first character |
| 569 | of their @code{variable-documentation} property. If the property exists |
| 570 | and is a string, and its first character is @samp{*}, then the variable |
| 571 | is a user option. Aliases of user options are also user options. |
| 572 | @end defun |
| 573 | |
| 574 | @kindex variable-interactive |
| 575 | If a user option variable has a @code{variable-interactive} property, |
| 576 | the @code{set-variable} command uses that value to control reading the |
| 577 | new value for the variable. The property's value is used as if it were |
| 578 | specified in @code{interactive} (@pxref{Using Interactive}). However, |
| 579 | this feature is largely obsoleted by @code{defcustom} |
| 580 | (@pxref{Customization}). |
| 581 | |
| 582 | @strong{Warning:} If the @code{defconst} and @code{defvar} special |
| 583 | forms are used while the variable has a local binding (made with |
| 584 | @code{let}, or a function argument), they set the local-binding's |
| 585 | value; the top-level binding is not changed. This is not what you |
| 586 | usually want. To prevent it, use these special forms at top level in |
| 587 | a file, where normally no local binding is in effect, and make sure to |
| 588 | load the file before making a local binding for the variable. |
| 589 | |
| 590 | @node Tips for Defining |
| 591 | @section Tips for Defining Variables Robustly |
| 592 | |
| 593 | When you define a variable whose value is a function, or a list of |
| 594 | functions, use a name that ends in @samp{-function} or |
| 595 | @samp{-functions}, respectively. |
| 596 | |
| 597 | There are several other variable name conventions; |
| 598 | here is a complete list: |
| 599 | |
| 600 | @table @samp |
| 601 | @item @dots{}-hook |
| 602 | The variable is a normal hook (@pxref{Hooks}). |
| 603 | |
| 604 | @item @dots{}-function |
| 605 | The value is a function. |
| 606 | |
| 607 | @item @dots{}-functions |
| 608 | The value is a list of functions. |
| 609 | |
| 610 | @item @dots{}-form |
| 611 | The value is a form (an expression). |
| 612 | |
| 613 | @item @dots{}-forms |
| 614 | The value is a list of forms (expressions). |
| 615 | |
| 616 | @item @dots{}-predicate |
| 617 | The value is a predicate---a function of one argument that returns |
| 618 | non-@code{nil} for ``good'' arguments and @code{nil} for ``bad'' |
| 619 | arguments. |
| 620 | |
| 621 | @item @dots{}-flag |
| 622 | The value is significant only as to whether it is @code{nil} or not. |
| 623 | |
| 624 | @item @dots{}-program |
| 625 | The value is a program name. |
| 626 | |
| 627 | @item @dots{}-command |
| 628 | The value is a whole shell command. |
| 629 | |
| 630 | @item @samp{}-switches |
| 631 | The value specifies options for a command. |
| 632 | @end table |
| 633 | |
| 634 | When you define a variable, always consider whether you should mark |
| 635 | it as ``risky''; see @ref{File Local Variables}. |
| 636 | |
| 637 | When defining and initializing a variable that holds a complicated |
| 638 | value (such as a keymap with bindings in it), it's best to put the |
| 639 | entire computation of the value into the @code{defvar}, like this: |
| 640 | |
| 641 | @example |
| 642 | (defvar my-mode-map |
| 643 | (let ((map (make-sparse-keymap))) |
| 644 | (define-key map "\C-c\C-a" 'my-command) |
| 645 | @dots{} |
| 646 | map) |
| 647 | @var{docstring}) |
| 648 | @end example |
| 649 | |
| 650 | @noindent |
| 651 | This method has several benefits. First, if the user quits while |
| 652 | loading the file, the variable is either still uninitialized or |
| 653 | initialized properly, never in-between. If it is still uninitialized, |
| 654 | reloading the file will initialize it properly. Second, reloading the |
| 655 | file once the variable is initialized will not alter it; that is |
| 656 | important if the user has run hooks to alter part of the contents (such |
| 657 | as, to rebind keys). Third, evaluating the @code{defvar} form with |
| 658 | @kbd{C-M-x} @emph{will} reinitialize the map completely. |
| 659 | |
| 660 | Putting so much code in the @code{defvar} form has one disadvantage: |
| 661 | it puts the documentation string far away from the line which names the |
| 662 | variable. Here's a safe way to avoid that: |
| 663 | |
| 664 | @example |
| 665 | (defvar my-mode-map nil |
| 666 | @var{docstring}) |
| 667 | (unless my-mode-map |
| 668 | (let ((map (make-sparse-keymap))) |
| 669 | (define-key map "\C-c\C-a" 'my-command) |
| 670 | @dots{} |
| 671 | (setq my-mode-map map))) |
| 672 | @end example |
| 673 | |
| 674 | @noindent |
| 675 | This has all the same advantages as putting the initialization inside |
| 676 | the @code{defvar}, except that you must type @kbd{C-M-x} twice, once on |
| 677 | each form, if you do want to reinitialize the variable. |
| 678 | |
| 679 | But be careful not to write the code like this: |
| 680 | |
| 681 | @example |
| 682 | (defvar my-mode-map nil |
| 683 | @var{docstring}) |
| 684 | (unless my-mode-map |
| 685 | (setq my-mode-map (make-sparse-keymap)) |
| 686 | (define-key my-mode-map "\C-c\C-a" 'my-command) |
| 687 | @dots{}) |
| 688 | @end example |
| 689 | |
| 690 | @noindent |
| 691 | This code sets the variable, then alters it, but it does so in more than |
| 692 | one step. If the user quits just after the @code{setq}, that leaves the |
| 693 | variable neither correctly initialized nor void nor @code{nil}. Once |
| 694 | that happens, reloading the file will not initialize the variable; it |
| 695 | will remain incomplete. |
| 696 | |
| 697 | @node Accessing Variables |
| 698 | @section Accessing Variable Values |
| 699 | |
| 700 | The usual way to reference a variable is to write the symbol which |
| 701 | names it (@pxref{Symbol Forms}). This requires you to specify the |
| 702 | variable name when you write the program. Usually that is exactly what |
| 703 | you want to do. Occasionally you need to choose at run time which |
| 704 | variable to reference; then you can use @code{symbol-value}. |
| 705 | |
| 706 | @defun symbol-value symbol |
| 707 | This function returns the value of @var{symbol}. This is the value in |
| 708 | the innermost local binding of the symbol, or its global value if it |
| 709 | has no local bindings. |
| 710 | |
| 711 | @example |
| 712 | @group |
| 713 | (setq abracadabra 5) |
| 714 | @result{} 5 |
| 715 | @end group |
| 716 | @group |
| 717 | (setq foo 9) |
| 718 | @result{} 9 |
| 719 | @end group |
| 720 | |
| 721 | @group |
| 722 | ;; @r{Here the symbol @code{abracadabra}} |
| 723 | ;; @r{is the symbol whose value is examined.} |
| 724 | (let ((abracadabra 'foo)) |
| 725 | (symbol-value 'abracadabra)) |
| 726 | @result{} foo |
| 727 | @end group |
| 728 | |
| 729 | @group |
| 730 | ;; @r{Here the value of @code{abracadabra},} |
| 731 | ;; @r{which is @code{foo},} |
| 732 | ;; @r{is the symbol whose value is examined.} |
| 733 | (let ((abracadabra 'foo)) |
| 734 | (symbol-value abracadabra)) |
| 735 | @result{} 9 |
| 736 | @end group |
| 737 | |
| 738 | @group |
| 739 | (symbol-value 'abracadabra) |
| 740 | @result{} 5 |
| 741 | @end group |
| 742 | @end example |
| 743 | |
| 744 | A @code{void-variable} error is signaled if the current binding of |
| 745 | @var{symbol} is void. |
| 746 | @end defun |
| 747 | |
| 748 | @node Setting Variables |
| 749 | @section How to Alter a Variable Value |
| 750 | |
| 751 | The usual way to change the value of a variable is with the special |
| 752 | form @code{setq}. When you need to compute the choice of variable at |
| 753 | run time, use the function @code{set}. |
| 754 | |
| 755 | @defspec setq [symbol form]@dots{} |
| 756 | This special form is the most common method of changing a variable's |
| 757 | value. Each @var{symbol} is given a new value, which is the result of |
| 758 | evaluating the corresponding @var{form}. The most-local existing |
| 759 | binding of the symbol is changed. |
| 760 | |
| 761 | @code{setq} does not evaluate @var{symbol}; it sets the symbol that you |
| 762 | write. We say that this argument is @dfn{automatically quoted}. The |
| 763 | @samp{q} in @code{setq} stands for ``quoted.'' |
| 764 | |
| 765 | The value of the @code{setq} form is the value of the last @var{form}. |
| 766 | |
| 767 | @example |
| 768 | @group |
| 769 | (setq x (1+ 2)) |
| 770 | @result{} 3 |
| 771 | @end group |
| 772 | x ; @r{@code{x} now has a global value.} |
| 773 | @result{} 3 |
| 774 | @group |
| 775 | (let ((x 5)) |
| 776 | (setq x 6) ; @r{The local binding of @code{x} is set.} |
| 777 | x) |
| 778 | @result{} 6 |
| 779 | @end group |
| 780 | x ; @r{The global value is unchanged.} |
| 781 | @result{} 3 |
| 782 | @end example |
| 783 | |
| 784 | Note that the first @var{form} is evaluated, then the first |
| 785 | @var{symbol} is set, then the second @var{form} is evaluated, then the |
| 786 | second @var{symbol} is set, and so on: |
| 787 | |
| 788 | @example |
| 789 | @group |
| 790 | (setq x 10 ; @r{Notice that @code{x} is set before} |
| 791 | y (1+ x)) ; @r{the value of @code{y} is computed.} |
| 792 | @result{} 11 |
| 793 | @end group |
| 794 | @end example |
| 795 | @end defspec |
| 796 | |
| 797 | @defun set symbol value |
| 798 | This function sets @var{symbol}'s value to @var{value}, then returns |
| 799 | @var{value}. Since @code{set} is a function, the expression written for |
| 800 | @var{symbol} is evaluated to obtain the symbol to set. |
| 801 | |
| 802 | The most-local existing binding of the variable is the binding that is |
| 803 | set; shadowed bindings are not affected. |
| 804 | |
| 805 | @example |
| 806 | @group |
| 807 | (set one 1) |
| 808 | @error{} Symbol's value as variable is void: one |
| 809 | @end group |
| 810 | @group |
| 811 | (set 'one 1) |
| 812 | @result{} 1 |
| 813 | @end group |
| 814 | @group |
| 815 | (set 'two 'one) |
| 816 | @result{} one |
| 817 | @end group |
| 818 | @group |
| 819 | (set two 2) ; @r{@code{two} evaluates to symbol @code{one}.} |
| 820 | @result{} 2 |
| 821 | @end group |
| 822 | @group |
| 823 | one ; @r{So it is @code{one} that was set.} |
| 824 | @result{} 2 |
| 825 | (let ((one 1)) ; @r{This binding of @code{one} is set,} |
| 826 | (set 'one 3) ; @r{not the global value.} |
| 827 | one) |
| 828 | @result{} 3 |
| 829 | @end group |
| 830 | @group |
| 831 | one |
| 832 | @result{} 2 |
| 833 | @end group |
| 834 | @end example |
| 835 | |
| 836 | If @var{symbol} is not actually a symbol, a @code{wrong-type-argument} |
| 837 | error is signaled. |
| 838 | |
| 839 | @example |
| 840 | (set '(x y) 'z) |
| 841 | @error{} Wrong type argument: symbolp, (x y) |
| 842 | @end example |
| 843 | |
| 844 | Logically speaking, @code{set} is a more fundamental primitive than |
| 845 | @code{setq}. Any use of @code{setq} can be trivially rewritten to use |
| 846 | @code{set}; @code{setq} could even be defined as a macro, given the |
| 847 | availability of @code{set}. However, @code{set} itself is rarely used; |
| 848 | beginners hardly need to know about it. It is useful only for choosing |
| 849 | at run time which variable to set. For example, the command |
| 850 | @code{set-variable}, which reads a variable name from the user and then |
| 851 | sets the variable, needs to use @code{set}. |
| 852 | |
| 853 | @cindex CL note---@code{set} local |
| 854 | @quotation |
| 855 | @b{Common Lisp note:} In Common Lisp, @code{set} always changes the |
| 856 | symbol's ``special'' or dynamic value, ignoring any lexical bindings. |
| 857 | In Emacs Lisp, all variables and all bindings are dynamic, so @code{set} |
| 858 | always affects the most local existing binding. |
| 859 | @end quotation |
| 860 | @end defun |
| 861 | |
| 862 | One other function for setting a variable is designed to add |
| 863 | an element to a list if it is not already present in the list. |
| 864 | |
| 865 | @defun add-to-list symbol element &optional append |
| 866 | This function sets the variable @var{symbol} by consing @var{element} |
| 867 | onto the old value, if @var{element} is not already a member of that |
| 868 | value. It returns the resulting list, whether updated or not. The |
| 869 | value of @var{symbol} had better be a list already before the call. |
| 870 | Membership is tested using @code{equal}. |
| 871 | |
| 872 | Normally, if @var{element} is added, it is added to the front of |
| 873 | @var{symbol}, but if the optional argument @var{append} is |
| 874 | non-@code{nil}, it is added at the end. |
| 875 | |
| 876 | The argument @var{symbol} is not implicitly quoted; @code{add-to-list} |
| 877 | is an ordinary function, like @code{set} and unlike @code{setq}. Quote |
| 878 | the argument yourself if that is what you want. |
| 879 | @end defun |
| 880 | |
| 881 | Here's a scenario showing how to use @code{add-to-list}: |
| 882 | |
| 883 | @example |
| 884 | (setq foo '(a b)) |
| 885 | @result{} (a b) |
| 886 | |
| 887 | (add-to-list 'foo 'c) ;; @r{Add @code{c}.} |
| 888 | @result{} (c a b) |
| 889 | |
| 890 | (add-to-list 'foo 'b) ;; @r{No effect.} |
| 891 | @result{} (c a b) |
| 892 | |
| 893 | foo ;; @r{@code{foo} was changed.} |
| 894 | @result{} (c a b) |
| 895 | @end example |
| 896 | |
| 897 | An equivalent expression for @code{(add-to-list '@var{var} |
| 898 | @var{value})} is this: |
| 899 | |
| 900 | @example |
| 901 | (or (member @var{value} @var{var}) |
| 902 | (setq @var{var} (cons @var{value} @var{var}))) |
| 903 | @end example |
| 904 | |
| 905 | @defun add-to-ordered-list symbol element &optional order |
| 906 | This function sets the variable @var{symbol} by inserting |
| 907 | @var{element} into the old value, which must be a list, at the |
| 908 | position specified by @var{order}. If @var{element} is already a |
| 909 | member of the list, its position in the list is adjusted according |
| 910 | to @var{order}. Membership is tested using @code{eq}. |
| 911 | This function returns the resulting list, whether updated or not. |
| 912 | |
| 913 | The @var{order} is typically a number (integer or float), and the |
| 914 | elements of the list are sorted in non-decreasing numerical order. |
| 915 | |
| 916 | @var{order} may also be omitted or @code{nil}. Then the numeric order |
| 917 | of @var{element} stays unchanged if it already has one; otherwise, |
| 918 | @var{element} has no numeric order. Elements without a numeric list |
| 919 | order are placed at the end of the list, in no particular order. |
| 920 | |
| 921 | Any other value for @var{order} removes the numeric order of @var{element} |
| 922 | if it already has one; otherwise, it is equivalent to @code{nil}. |
| 923 | |
| 924 | The argument @var{symbol} is not implicitly quoted; |
| 925 | @code{add-to-ordered-list} is an ordinary function, like @code{set} |
| 926 | and unlike @code{setq}. Quote the argument yourself if that is what |
| 927 | you want. |
| 928 | |
| 929 | The ordering information is stored in a hash table on @var{symbol}'s |
| 930 | @code{list-order} property. |
| 931 | @end defun |
| 932 | |
| 933 | Here's a scenario showing how to use @code{add-to-ordered-list}: |
| 934 | |
| 935 | @example |
| 936 | (setq foo '()) |
| 937 | @result{} nil |
| 938 | |
| 939 | (add-to-ordered-list 'foo 'a 1) ;; @r{Add @code{a}.} |
| 940 | @result{} (a) |
| 941 | |
| 942 | (add-to-ordered-list 'foo 'c 3) ;; @r{Add @code{c}.} |
| 943 | @result{} (a c) |
| 944 | |
| 945 | (add-to-ordered-list 'foo 'b 2) ;; @r{Add @code{b}.} |
| 946 | @result{} (a b c) |
| 947 | |
| 948 | (add-to-ordered-list 'foo 'b 4) ;; @r{Move @code{b}.} |
| 949 | @result{} (a c b) |
| 950 | |
| 951 | (add-to-ordered-list 'foo 'd) ;; @r{Append @code{d}.} |
| 952 | @result{} (a c b d) |
| 953 | |
| 954 | (add-to-ordered-list 'foo 'e) ;; @r{Add @code{e}}. |
| 955 | @result{} (a c b e d) |
| 956 | |
| 957 | foo ;; @r{@code{foo} was changed.} |
| 958 | @result{} (a c b e d) |
| 959 | @end example |
| 960 | |
| 961 | @node Variable Scoping |
| 962 | @section Scoping Rules for Variable Bindings |
| 963 | |
| 964 | A given symbol @code{foo} can have several local variable bindings, |
| 965 | established at different places in the Lisp program, as well as a global |
| 966 | binding. The most recently established binding takes precedence over |
| 967 | the others. |
| 968 | |
| 969 | @cindex scope |
| 970 | @cindex extent |
| 971 | @cindex dynamic scoping |
| 972 | @cindex lexical scoping |
| 973 | Local bindings in Emacs Lisp have @dfn{indefinite scope} and |
| 974 | @dfn{dynamic extent}. @dfn{Scope} refers to @emph{where} textually in |
| 975 | the source code the binding can be accessed. ``Indefinite scope'' means |
| 976 | that any part of the program can potentially access the variable |
| 977 | binding. @dfn{Extent} refers to @emph{when}, as the program is |
| 978 | executing, the binding exists. ``Dynamic extent'' means that the binding |
| 979 | lasts as long as the activation of the construct that established it. |
| 980 | |
| 981 | The combination of dynamic extent and indefinite scope is called |
| 982 | @dfn{dynamic scoping}. By contrast, most programming languages use |
| 983 | @dfn{lexical scoping}, in which references to a local variable must be |
| 984 | located textually within the function or block that binds the variable. |
| 985 | |
| 986 | @cindex CL note---special variables |
| 987 | @quotation |
| 988 | @b{Common Lisp note:} Variables declared ``special'' in Common Lisp are |
| 989 | dynamically scoped, like all variables in Emacs Lisp. |
| 990 | @end quotation |
| 991 | |
| 992 | @menu |
| 993 | * Scope:: Scope means where in the program a value is visible. |
| 994 | Comparison with other languages. |
| 995 | * Extent:: Extent means how long in time a value exists. |
| 996 | * Impl of Scope:: Two ways to implement dynamic scoping. |
| 997 | * Using Scoping:: How to use dynamic scoping carefully and avoid problems. |
| 998 | @end menu |
| 999 | |
| 1000 | @node Scope |
| 1001 | @subsection Scope |
| 1002 | |
| 1003 | Emacs Lisp uses @dfn{indefinite scope} for local variable bindings. |
| 1004 | This means that any function anywhere in the program text might access a |
| 1005 | given binding of a variable. Consider the following function |
| 1006 | definitions: |
| 1007 | |
| 1008 | @example |
| 1009 | @group |
| 1010 | (defun binder (x) ; @r{@code{x} is bound in @code{binder}.} |
| 1011 | (foo 5)) ; @r{@code{foo} is some other function.} |
| 1012 | @end group |
| 1013 | |
| 1014 | @group |
| 1015 | (defun user () ; @r{@code{x} is used ``free'' in @code{user}.} |
| 1016 | (list x)) |
| 1017 | @end group |
| 1018 | @end example |
| 1019 | |
| 1020 | In a lexically scoped language, the binding of @code{x} in |
| 1021 | @code{binder} would never be accessible in @code{user}, because |
| 1022 | @code{user} is not textually contained within the function |
| 1023 | @code{binder}. However, in dynamically-scoped Emacs Lisp, @code{user} |
| 1024 | may or may not refer to the binding of @code{x} established in |
| 1025 | @code{binder}, depending on the circumstances: |
| 1026 | |
| 1027 | @itemize @bullet |
| 1028 | @item |
| 1029 | If we call @code{user} directly without calling @code{binder} at all, |
| 1030 | then whatever binding of @code{x} is found, it cannot come from |
| 1031 | @code{binder}. |
| 1032 | |
| 1033 | @item |
| 1034 | If we define @code{foo} as follows and then call @code{binder}, then the |
| 1035 | binding made in @code{binder} will be seen in @code{user}: |
| 1036 | |
| 1037 | @example |
| 1038 | @group |
| 1039 | (defun foo (lose) |
| 1040 | (user)) |
| 1041 | @end group |
| 1042 | @end example |
| 1043 | |
| 1044 | @item |
| 1045 | However, if we define @code{foo} as follows and then call @code{binder}, |
| 1046 | then the binding made in @code{binder} @emph{will not} be seen in |
| 1047 | @code{user}: |
| 1048 | |
| 1049 | @example |
| 1050 | (defun foo (x) |
| 1051 | (user)) |
| 1052 | @end example |
| 1053 | |
| 1054 | @noindent |
| 1055 | Here, when @code{foo} is called by @code{binder}, it binds @code{x}. |
| 1056 | (The binding in @code{foo} is said to @dfn{shadow} the one made in |
| 1057 | @code{binder}.) Therefore, @code{user} will access the @code{x} bound |
| 1058 | by @code{foo} instead of the one bound by @code{binder}. |
| 1059 | @end itemize |
| 1060 | |
| 1061 | Emacs Lisp uses dynamic scoping because simple implementations of |
| 1062 | lexical scoping are slow. In addition, every Lisp system needs to offer |
| 1063 | dynamic scoping at least as an option; if lexical scoping is the norm, |
| 1064 | there must be a way to specify dynamic scoping instead for a particular |
| 1065 | variable. It might not be a bad thing for Emacs to offer both, but |
| 1066 | implementing it with dynamic scoping only was much easier. |
| 1067 | |
| 1068 | @node Extent |
| 1069 | @subsection Extent |
| 1070 | |
| 1071 | @dfn{Extent} refers to the time during program execution that a |
| 1072 | variable name is valid. In Emacs Lisp, a variable is valid only while |
| 1073 | the form that bound it is executing. This is called @dfn{dynamic |
| 1074 | extent}. ``Local'' or ``automatic'' variables in most languages, |
| 1075 | including C and Pascal, have dynamic extent. |
| 1076 | |
| 1077 | One alternative to dynamic extent is @dfn{indefinite extent}. This |
| 1078 | means that a variable binding can live on past the exit from the form |
| 1079 | that made the binding. Common Lisp and Scheme, for example, support |
| 1080 | this, but Emacs Lisp does not. |
| 1081 | |
| 1082 | To illustrate this, the function below, @code{make-add}, returns a |
| 1083 | function that purports to add @var{n} to its own argument @var{m}. This |
| 1084 | would work in Common Lisp, but it does not do the job in Emacs Lisp, |
| 1085 | because after the call to @code{make-add} exits, the variable @code{n} |
| 1086 | is no longer bound to the actual argument 2. |
| 1087 | |
| 1088 | @example |
| 1089 | (defun make-add (n) |
| 1090 | (function (lambda (m) (+ n m)))) ; @r{Return a function.} |
| 1091 | @result{} make-add |
| 1092 | (fset 'add2 (make-add 2)) ; @r{Define function @code{add2}} |
| 1093 | ; @r{with @code{(make-add 2)}.} |
| 1094 | @result{} (lambda (m) (+ n m)) |
| 1095 | (add2 4) ; @r{Try to add 2 to 4.} |
| 1096 | @error{} Symbol's value as variable is void: n |
| 1097 | @end example |
| 1098 | |
| 1099 | @cindex closures not available |
| 1100 | Some Lisp dialects have ``closures'', objects that are like functions |
| 1101 | but record additional variable bindings. Emacs Lisp does not have |
| 1102 | closures. |
| 1103 | |
| 1104 | @node Impl of Scope |
| 1105 | @subsection Implementation of Dynamic Scoping |
| 1106 | @cindex deep binding |
| 1107 | |
| 1108 | A simple sample implementation (which is not how Emacs Lisp actually |
| 1109 | works) may help you understand dynamic binding. This technique is |
| 1110 | called @dfn{deep binding} and was used in early Lisp systems. |
| 1111 | |
| 1112 | Suppose there is a stack of bindings, which are variable-value pairs. |
| 1113 | At entry to a function or to a @code{let} form, we can push bindings |
| 1114 | onto the stack for the arguments or local variables created there. We |
| 1115 | can pop those bindings from the stack at exit from the binding |
| 1116 | construct. |
| 1117 | |
| 1118 | We can find the value of a variable by searching the stack from top to |
| 1119 | bottom for a binding for that variable; the value from that binding is |
| 1120 | the value of the variable. To set the variable, we search for the |
| 1121 | current binding, then store the new value into that binding. |
| 1122 | |
| 1123 | As you can see, a function's bindings remain in effect as long as it |
| 1124 | continues execution, even during its calls to other functions. That is |
| 1125 | why we say the extent of the binding is dynamic. And any other function |
| 1126 | can refer to the bindings, if it uses the same variables while the |
| 1127 | bindings are in effect. That is why we say the scope is indefinite. |
| 1128 | |
| 1129 | @cindex shallow binding |
| 1130 | The actual implementation of variable scoping in GNU Emacs Lisp uses a |
| 1131 | technique called @dfn{shallow binding}. Each variable has a standard |
| 1132 | place in which its current value is always found---the value cell of the |
| 1133 | symbol. |
| 1134 | |
| 1135 | In shallow binding, setting the variable works by storing a value in |
| 1136 | the value cell. Creating a new binding works by pushing the old value |
| 1137 | (belonging to a previous binding) onto a stack, and storing the new |
| 1138 | local value in the value cell. Eliminating a binding works by popping |
| 1139 | the old value off the stack, into the value cell. |
| 1140 | |
| 1141 | We use shallow binding because it has the same results as deep |
| 1142 | binding, but runs faster, since there is never a need to search for a |
| 1143 | binding. |
| 1144 | |
| 1145 | @node Using Scoping |
| 1146 | @subsection Proper Use of Dynamic Scoping |
| 1147 | |
| 1148 | Binding a variable in one function and using it in another is a |
| 1149 | powerful technique, but if used without restraint, it can make programs |
| 1150 | hard to understand. There are two clean ways to use this technique: |
| 1151 | |
| 1152 | @itemize @bullet |
| 1153 | @item |
| 1154 | Use or bind the variable only in a few related functions, written close |
| 1155 | together in one file. Such a variable is used for communication within |
| 1156 | one program. |
| 1157 | |
| 1158 | You should write comments to inform other programmers that they can see |
| 1159 | all uses of the variable before them, and to advise them not to add uses |
| 1160 | elsewhere. |
| 1161 | |
| 1162 | @item |
| 1163 | Give the variable a well-defined, documented meaning, and make all |
| 1164 | appropriate functions refer to it (but not bind it or set it) wherever |
| 1165 | that meaning is relevant. For example, the variable |
| 1166 | @code{case-fold-search} is defined as ``non-@code{nil} means ignore case |
| 1167 | when searching''; various search and replace functions refer to it |
| 1168 | directly or through their subroutines, but do not bind or set it. |
| 1169 | |
| 1170 | Then you can bind the variable in other programs, knowing reliably what |
| 1171 | the effect will be. |
| 1172 | @end itemize |
| 1173 | |
| 1174 | In either case, you should define the variable with @code{defvar}. |
| 1175 | This helps other people understand your program by telling them to look |
| 1176 | for inter-function usage. It also avoids a warning from the byte |
| 1177 | compiler. Choose the variable's name to avoid name conflicts---don't |
| 1178 | use short names like @code{x}. |
| 1179 | |
| 1180 | @node Buffer-Local Variables |
| 1181 | @section Buffer-Local Variables |
| 1182 | @cindex variables, buffer-local |
| 1183 | @cindex buffer-local variables |
| 1184 | |
| 1185 | Global and local variable bindings are found in most programming |
| 1186 | languages in one form or another. Emacs, however, also supports additional, |
| 1187 | unusual kinds of variable binding: @dfn{buffer-local} bindings, which |
| 1188 | apply only in one buffer, and @dfn{frame-local} bindings, which apply only in |
| 1189 | one frame. Having different values for a variable in different buffers |
| 1190 | and/or frames is an important customization method. |
| 1191 | |
| 1192 | This section describes buffer-local bindings; for frame-local |
| 1193 | bindings, see the following section, @ref{Frame-Local Variables}. (A few |
| 1194 | variables have bindings that are local to each terminal; see |
| 1195 | @ref{Multiple Displays}.) |
| 1196 | |
| 1197 | @menu |
| 1198 | * Intro to Buffer-Local:: Introduction and concepts. |
| 1199 | * Creating Buffer-Local:: Creating and destroying buffer-local bindings. |
| 1200 | * Default Value:: The default value is seen in buffers |
| 1201 | that don't have their own buffer-local values. |
| 1202 | @end menu |
| 1203 | |
| 1204 | @node Intro to Buffer-Local |
| 1205 | @subsection Introduction to Buffer-Local Variables |
| 1206 | |
| 1207 | A buffer-local variable has a buffer-local binding associated with a |
| 1208 | particular buffer. The binding is in effect when that buffer is |
| 1209 | current; otherwise, it is not in effect. If you set the variable while |
| 1210 | a buffer-local binding is in effect, the new value goes in that binding, |
| 1211 | so its other bindings are unchanged. This means that the change is |
| 1212 | visible only in the buffer where you made it. |
| 1213 | |
| 1214 | The variable's ordinary binding, which is not associated with any |
| 1215 | specific buffer, is called the @dfn{default binding}. In most cases, |
| 1216 | this is the global binding. |
| 1217 | |
| 1218 | A variable can have buffer-local bindings in some buffers but not in |
| 1219 | other buffers. The default binding is shared by all the buffers that |
| 1220 | don't have their own bindings for the variable. (This includes all |
| 1221 | newly-created buffers.) If you set the variable in a buffer that does |
| 1222 | not have a buffer-local binding for it, this sets the default binding |
| 1223 | (assuming there are no frame-local bindings to complicate the matter), |
| 1224 | so the new value is visible in all the buffers that see the default |
| 1225 | binding. |
| 1226 | |
| 1227 | The most common use of buffer-local bindings is for major modes to change |
| 1228 | variables that control the behavior of commands. For example, C mode and |
| 1229 | Lisp mode both set the variable @code{paragraph-start} to specify that only |
| 1230 | blank lines separate paragraphs. They do this by making the variable |
| 1231 | buffer-local in the buffer that is being put into C mode or Lisp mode, and |
| 1232 | then setting it to the new value for that mode. @xref{Major Modes}. |
| 1233 | |
| 1234 | The usual way to make a buffer-local binding is with |
| 1235 | @code{make-local-variable}, which is what major mode commands typically |
| 1236 | use. This affects just the current buffer; all other buffers (including |
| 1237 | those yet to be created) will continue to share the default value unless |
| 1238 | they are explicitly given their own buffer-local bindings. |
| 1239 | |
| 1240 | @cindex automatically buffer-local |
| 1241 | A more powerful operation is to mark the variable as |
| 1242 | @dfn{automatically buffer-local} by calling |
| 1243 | @code{make-variable-buffer-local}. You can think of this as making the |
| 1244 | variable local in all buffers, even those yet to be created. More |
| 1245 | precisely, the effect is that setting the variable automatically makes |
| 1246 | the variable local to the current buffer if it is not already so. All |
| 1247 | buffers start out by sharing the default value of the variable as usual, |
| 1248 | but setting the variable creates a buffer-local binding for the current |
| 1249 | buffer. The new value is stored in the buffer-local binding, leaving |
| 1250 | the default binding untouched. This means that the default value cannot |
| 1251 | be changed with @code{setq} in any buffer; the only way to change it is |
| 1252 | with @code{setq-default}. |
| 1253 | |
| 1254 | @strong{Warning:} When a variable has buffer-local or frame-local |
| 1255 | bindings in one or more buffers, @code{let} rebinds the binding that's |
| 1256 | currently in effect. For instance, if the current buffer has a |
| 1257 | buffer-local value, @code{let} temporarily rebinds that. If no |
| 1258 | buffer-local or frame-local bindings are in effect, @code{let} rebinds |
| 1259 | the default value. If inside the @code{let} you then change to a |
| 1260 | different current buffer in which a different binding is in effect, |
| 1261 | you won't see the @code{let} binding any more. And if you exit the |
| 1262 | @code{let} while still in the other buffer, you won't see the |
| 1263 | unbinding occur (though it will occur properly). Here is an example |
| 1264 | to illustrate: |
| 1265 | |
| 1266 | @example |
| 1267 | @group |
| 1268 | (setq foo 'g) |
| 1269 | (set-buffer "a") |
| 1270 | (make-local-variable 'foo) |
| 1271 | @end group |
| 1272 | (setq foo 'a) |
| 1273 | (let ((foo 'temp)) |
| 1274 | ;; foo @result{} 'temp ; @r{let binding in buffer @samp{a}} |
| 1275 | (set-buffer "b") |
| 1276 | ;; foo @result{} 'g ; @r{the global value since foo is not local in @samp{b}} |
| 1277 | @var{body}@dots{}) |
| 1278 | @group |
| 1279 | foo @result{} 'g ; @r{exiting restored the local value in buffer @samp{a},} |
| 1280 | ; @r{but we don't see that in buffer @samp{b}} |
| 1281 | @end group |
| 1282 | @group |
| 1283 | (set-buffer "a") ; @r{verify the local value was restored} |
| 1284 | foo @result{} 'a |
| 1285 | @end group |
| 1286 | @end example |
| 1287 | |
| 1288 | Note that references to @code{foo} in @var{body} access the |
| 1289 | buffer-local binding of buffer @samp{b}. |
| 1290 | |
| 1291 | When a file specifies local variable values, these become buffer-local |
| 1292 | values when you visit the file. @xref{File Variables,,, emacs, The |
| 1293 | GNU Emacs Manual}. |
| 1294 | |
| 1295 | @node Creating Buffer-Local |
| 1296 | @subsection Creating and Deleting Buffer-Local Bindings |
| 1297 | |
| 1298 | @deffn Command make-local-variable variable |
| 1299 | This function creates a buffer-local binding in the current buffer for |
| 1300 | @var{variable} (a symbol). Other buffers are not affected. The value |
| 1301 | returned is @var{variable}. |
| 1302 | |
| 1303 | @c Emacs 19 feature |
| 1304 | The buffer-local value of @var{variable} starts out as the same value |
| 1305 | @var{variable} previously had. If @var{variable} was void, it remains |
| 1306 | void. |
| 1307 | |
| 1308 | @example |
| 1309 | @group |
| 1310 | ;; @r{In buffer @samp{b1}:} |
| 1311 | (setq foo 5) ; @r{Affects all buffers.} |
| 1312 | @result{} 5 |
| 1313 | @end group |
| 1314 | @group |
| 1315 | (make-local-variable 'foo) ; @r{Now it is local in @samp{b1}.} |
| 1316 | @result{} foo |
| 1317 | @end group |
| 1318 | @group |
| 1319 | foo ; @r{That did not change} |
| 1320 | @result{} 5 ; @r{the value.} |
| 1321 | @end group |
| 1322 | @group |
| 1323 | (setq foo 6) ; @r{Change the value} |
| 1324 | @result{} 6 ; @r{in @samp{b1}.} |
| 1325 | @end group |
| 1326 | @group |
| 1327 | foo |
| 1328 | @result{} 6 |
| 1329 | @end group |
| 1330 | |
| 1331 | @group |
| 1332 | ;; @r{In buffer @samp{b2}, the value hasn't changed.} |
| 1333 | (save-excursion |
| 1334 | (set-buffer "b2") |
| 1335 | foo) |
| 1336 | @result{} 5 |
| 1337 | @end group |
| 1338 | @end example |
| 1339 | |
| 1340 | Making a variable buffer-local within a @code{let}-binding for that |
| 1341 | variable does not work reliably, unless the buffer in which you do this |
| 1342 | is not current either on entry to or exit from the @code{let}. This is |
| 1343 | because @code{let} does not distinguish between different kinds of |
| 1344 | bindings; it knows only which variable the binding was made for. |
| 1345 | |
| 1346 | If the variable is terminal-local, this function signals an error. Such |
| 1347 | variables cannot have buffer-local bindings as well. @xref{Multiple |
| 1348 | Displays}. |
| 1349 | |
| 1350 | @strong{Warning:} do not use @code{make-local-variable} for a hook |
| 1351 | variable. The hook variables are automatically made buffer-local as |
| 1352 | needed if you use the @var{local} argument to @code{add-hook} or |
| 1353 | @code{remove-hook}. |
| 1354 | @end deffn |
| 1355 | |
| 1356 | @deffn Command make-variable-buffer-local variable |
| 1357 | This function marks @var{variable} (a symbol) automatically |
| 1358 | buffer-local, so that any subsequent attempt to set it will make it |
| 1359 | local to the current buffer at the time. |
| 1360 | |
| 1361 | A peculiar wrinkle of this feature is that binding the variable (with |
| 1362 | @code{let} or other binding constructs) does not create a buffer-local |
| 1363 | binding for it. Only setting the variable (with @code{set} or |
| 1364 | @code{setq}), while the variable does not have a @code{let}-style |
| 1365 | binding that was made in the current buffer, does so. |
| 1366 | |
| 1367 | If @var{variable} does not have a default value, then calling this |
| 1368 | command will give it a default value of @code{nil}. If @var{variable} |
| 1369 | already has a default value, that value remains unchanged. |
| 1370 | Subsequently calling @code{makunbound} on @var{variable} will result |
| 1371 | in a void buffer-local value and leave the default value unaffected. |
| 1372 | |
| 1373 | The value returned is @var{variable}. |
| 1374 | |
| 1375 | @strong{Warning:} Don't assume that you should use |
| 1376 | @code{make-variable-buffer-local} for user-option variables, simply |
| 1377 | because users @emph{might} want to customize them differently in |
| 1378 | different buffers. Users can make any variable local, when they wish |
| 1379 | to. It is better to leave the choice to them. |
| 1380 | |
| 1381 | The time to use @code{make-variable-buffer-local} is when it is crucial |
| 1382 | that no two buffers ever share the same binding. For example, when a |
| 1383 | variable is used for internal purposes in a Lisp program which depends |
| 1384 | on having separate values in separate buffers, then using |
| 1385 | @code{make-variable-buffer-local} can be the best solution. |
| 1386 | @end deffn |
| 1387 | |
| 1388 | @defun local-variable-p variable &optional buffer |
| 1389 | This returns @code{t} if @var{variable} is buffer-local in buffer |
| 1390 | @var{buffer} (which defaults to the current buffer); otherwise, |
| 1391 | @code{nil}. |
| 1392 | @end defun |
| 1393 | |
| 1394 | @defun local-variable-if-set-p variable &optional buffer |
| 1395 | This returns @code{t} if @var{variable} will become buffer-local in |
| 1396 | buffer @var{buffer} (which defaults to the current buffer) if it is |
| 1397 | set there. |
| 1398 | @end defun |
| 1399 | |
| 1400 | @defun buffer-local-value variable buffer |
| 1401 | This function returns the buffer-local binding of @var{variable} (a |
| 1402 | symbol) in buffer @var{buffer}. If @var{variable} does not have a |
| 1403 | buffer-local binding in buffer @var{buffer}, it returns the default |
| 1404 | value (@pxref{Default Value}) of @var{variable} instead. |
| 1405 | @end defun |
| 1406 | |
| 1407 | @defun buffer-local-variables &optional buffer |
| 1408 | This function returns a list describing the buffer-local variables in |
| 1409 | buffer @var{buffer}. (If @var{buffer} is omitted, the current buffer is |
| 1410 | used.) It returns an association list (@pxref{Association Lists}) in |
| 1411 | which each element contains one buffer-local variable and its value. |
| 1412 | However, when a variable's buffer-local binding in @var{buffer} is void, |
| 1413 | then the variable appears directly in the resulting list. |
| 1414 | |
| 1415 | @example |
| 1416 | @group |
| 1417 | (make-local-variable 'foobar) |
| 1418 | (makunbound 'foobar) |
| 1419 | (make-local-variable 'bind-me) |
| 1420 | (setq bind-me 69) |
| 1421 | @end group |
| 1422 | (setq lcl (buffer-local-variables)) |
| 1423 | ;; @r{First, built-in variables local in all buffers:} |
| 1424 | @result{} ((mark-active . nil) |
| 1425 | (buffer-undo-list . nil) |
| 1426 | (mode-name . "Fundamental") |
| 1427 | @dots{} |
| 1428 | @group |
| 1429 | ;; @r{Next, non-built-in buffer-local variables.} |
| 1430 | ;; @r{This one is buffer-local and void:} |
| 1431 | foobar |
| 1432 | ;; @r{This one is buffer-local and nonvoid:} |
| 1433 | (bind-me . 69)) |
| 1434 | @end group |
| 1435 | @end example |
| 1436 | |
| 1437 | Note that storing new values into the @sc{cdr}s of cons cells in this |
| 1438 | list does @emph{not} change the buffer-local values of the variables. |
| 1439 | @end defun |
| 1440 | |
| 1441 | @deffn Command kill-local-variable variable |
| 1442 | This function deletes the buffer-local binding (if any) for |
| 1443 | @var{variable} (a symbol) in the current buffer. As a result, the |
| 1444 | default binding of @var{variable} becomes visible in this buffer. This |
| 1445 | typically results in a change in the value of @var{variable}, since the |
| 1446 | default value is usually different from the buffer-local value just |
| 1447 | eliminated. |
| 1448 | |
| 1449 | If you kill the buffer-local binding of a variable that automatically |
| 1450 | becomes buffer-local when set, this makes the default value visible in |
| 1451 | the current buffer. However, if you set the variable again, that will |
| 1452 | once again create a buffer-local binding for it. |
| 1453 | |
| 1454 | @code{kill-local-variable} returns @var{variable}. |
| 1455 | |
| 1456 | This function is a command because it is sometimes useful to kill one |
| 1457 | buffer-local variable interactively, just as it is useful to create |
| 1458 | buffer-local variables interactively. |
| 1459 | @end deffn |
| 1460 | |
| 1461 | @defun kill-all-local-variables |
| 1462 | This function eliminates all the buffer-local variable bindings of the |
| 1463 | current buffer except for variables marked as ``permanent''. As a |
| 1464 | result, the buffer will see the default values of most variables. |
| 1465 | |
| 1466 | This function also resets certain other information pertaining to the |
| 1467 | buffer: it sets the local keymap to @code{nil}, the syntax table to the |
| 1468 | value of @code{(standard-syntax-table)}, the case table to |
| 1469 | @code{(standard-case-table)}, and the abbrev table to the value of |
| 1470 | @code{fundamental-mode-abbrev-table}. |
| 1471 | |
| 1472 | The very first thing this function does is run the normal hook |
| 1473 | @code{change-major-mode-hook} (see below). |
| 1474 | |
| 1475 | Every major mode command begins by calling this function, which has the |
| 1476 | effect of switching to Fundamental mode and erasing most of the effects |
| 1477 | of the previous major mode. To ensure that this does its job, the |
| 1478 | variables that major modes set should not be marked permanent. |
| 1479 | |
| 1480 | @code{kill-all-local-variables} returns @code{nil}. |
| 1481 | @end defun |
| 1482 | |
| 1483 | @defvar change-major-mode-hook |
| 1484 | The function @code{kill-all-local-variables} runs this normal hook |
| 1485 | before it does anything else. This gives major modes a way to arrange |
| 1486 | for something special to be done if the user switches to a different |
| 1487 | major mode. It is also useful for buffer-specific minor modes |
| 1488 | that should be forgotten if the user changes the major mode. |
| 1489 | |
| 1490 | For best results, make this variable buffer-local, so that it will |
| 1491 | disappear after doing its job and will not interfere with the |
| 1492 | subsequent major mode. @xref{Hooks}. |
| 1493 | @end defvar |
| 1494 | |
| 1495 | @c Emacs 19 feature |
| 1496 | @cindex permanent local variable |
| 1497 | A buffer-local variable is @dfn{permanent} if the variable name (a |
| 1498 | symbol) has a @code{permanent-local} property that is non-@code{nil}. |
| 1499 | Permanent locals are appropriate for data pertaining to where the file |
| 1500 | came from or how to save it, rather than with how to edit the contents. |
| 1501 | |
| 1502 | @node Default Value |
| 1503 | @subsection The Default Value of a Buffer-Local Variable |
| 1504 | @cindex default value |
| 1505 | |
| 1506 | The global value of a variable with buffer-local bindings is also |
| 1507 | called the @dfn{default} value, because it is the value that is in |
| 1508 | effect whenever neither the current buffer nor the selected frame has |
| 1509 | its own binding for the variable. |
| 1510 | |
| 1511 | The functions @code{default-value} and @code{setq-default} access and |
| 1512 | change a variable's default value regardless of whether the current |
| 1513 | buffer has a buffer-local binding. For example, you could use |
| 1514 | @code{setq-default} to change the default setting of |
| 1515 | @code{paragraph-start} for most buffers; and this would work even when |
| 1516 | you are in a C or Lisp mode buffer that has a buffer-local value for |
| 1517 | this variable. |
| 1518 | |
| 1519 | @c Emacs 19 feature |
| 1520 | The special forms @code{defvar} and @code{defconst} also set the |
| 1521 | default value (if they set the variable at all), rather than any |
| 1522 | buffer-local or frame-local value. |
| 1523 | |
| 1524 | @defun default-value symbol |
| 1525 | This function returns @var{symbol}'s default value. This is the value |
| 1526 | that is seen in buffers and frames that do not have their own values for |
| 1527 | this variable. If @var{symbol} is not buffer-local, this is equivalent |
| 1528 | to @code{symbol-value} (@pxref{Accessing Variables}). |
| 1529 | @end defun |
| 1530 | |
| 1531 | @c Emacs 19 feature |
| 1532 | @defun default-boundp symbol |
| 1533 | The function @code{default-boundp} tells you whether @var{symbol}'s |
| 1534 | default value is nonvoid. If @code{(default-boundp 'foo)} returns |
| 1535 | @code{nil}, then @code{(default-value 'foo)} would get an error. |
| 1536 | |
| 1537 | @code{default-boundp} is to @code{default-value} as @code{boundp} is to |
| 1538 | @code{symbol-value}. |
| 1539 | @end defun |
| 1540 | |
| 1541 | @defspec setq-default [symbol form]@dots{} |
| 1542 | This special form gives each @var{symbol} a new default value, which is |
| 1543 | the result of evaluating the corresponding @var{form}. It does not |
| 1544 | evaluate @var{symbol}, but does evaluate @var{form}. The value of the |
| 1545 | @code{setq-default} form is the value of the last @var{form}. |
| 1546 | |
| 1547 | If a @var{symbol} is not buffer-local for the current buffer, and is not |
| 1548 | marked automatically buffer-local, @code{setq-default} has the same |
| 1549 | effect as @code{setq}. If @var{symbol} is buffer-local for the current |
| 1550 | buffer, then this changes the value that other buffers will see (as long |
| 1551 | as they don't have a buffer-local value), but not the value that the |
| 1552 | current buffer sees. |
| 1553 | |
| 1554 | @example |
| 1555 | @group |
| 1556 | ;; @r{In buffer @samp{foo}:} |
| 1557 | (make-local-variable 'buffer-local) |
| 1558 | @result{} buffer-local |
| 1559 | @end group |
| 1560 | @group |
| 1561 | (setq buffer-local 'value-in-foo) |
| 1562 | @result{} value-in-foo |
| 1563 | @end group |
| 1564 | @group |
| 1565 | (setq-default buffer-local 'new-default) |
| 1566 | @result{} new-default |
| 1567 | @end group |
| 1568 | @group |
| 1569 | buffer-local |
| 1570 | @result{} value-in-foo |
| 1571 | @end group |
| 1572 | @group |
| 1573 | (default-value 'buffer-local) |
| 1574 | @result{} new-default |
| 1575 | @end group |
| 1576 | |
| 1577 | @group |
| 1578 | ;; @r{In (the new) buffer @samp{bar}:} |
| 1579 | buffer-local |
| 1580 | @result{} new-default |
| 1581 | @end group |
| 1582 | @group |
| 1583 | (default-value 'buffer-local) |
| 1584 | @result{} new-default |
| 1585 | @end group |
| 1586 | @group |
| 1587 | (setq buffer-local 'another-default) |
| 1588 | @result{} another-default |
| 1589 | @end group |
| 1590 | @group |
| 1591 | (default-value 'buffer-local) |
| 1592 | @result{} another-default |
| 1593 | @end group |
| 1594 | |
| 1595 | @group |
| 1596 | ;; @r{Back in buffer @samp{foo}:} |
| 1597 | buffer-local |
| 1598 | @result{} value-in-foo |
| 1599 | (default-value 'buffer-local) |
| 1600 | @result{} another-default |
| 1601 | @end group |
| 1602 | @end example |
| 1603 | @end defspec |
| 1604 | |
| 1605 | @defun set-default symbol value |
| 1606 | This function is like @code{setq-default}, except that @var{symbol} is |
| 1607 | an ordinary evaluated argument. |
| 1608 | |
| 1609 | @example |
| 1610 | @group |
| 1611 | (set-default (car '(a b c)) 23) |
| 1612 | @result{} 23 |
| 1613 | @end group |
| 1614 | @group |
| 1615 | (default-value 'a) |
| 1616 | @result{} 23 |
| 1617 | @end group |
| 1618 | @end example |
| 1619 | @end defun |
| 1620 | |
| 1621 | @node Frame-Local Variables |
| 1622 | @section Frame-Local Variables |
| 1623 | |
| 1624 | Just as variables can have buffer-local bindings, they can also have |
| 1625 | frame-local bindings. These bindings belong to one frame, and are in |
| 1626 | effect when that frame is selected. Frame-local bindings are actually |
| 1627 | frame parameters: you create a frame-local binding in a specific frame |
| 1628 | by calling @code{modify-frame-parameters} and specifying the variable |
| 1629 | name as the parameter name. |
| 1630 | |
| 1631 | To enable frame-local bindings for a certain variable, call the function |
| 1632 | @code{make-variable-frame-local}. |
| 1633 | |
| 1634 | @deffn Command make-variable-frame-local variable |
| 1635 | Enable the use of frame-local bindings for @var{variable}. This does |
| 1636 | not in itself create any frame-local bindings for the variable; however, |
| 1637 | if some frame already has a value for @var{variable} as a frame |
| 1638 | parameter, that value automatically becomes a frame-local binding. |
| 1639 | |
| 1640 | If @var{variable} does not have a default value, then calling this |
| 1641 | command will give it a default value of @code{nil}. If @var{variable} |
| 1642 | already has a default value, that value remains unchanged. |
| 1643 | |
| 1644 | If the variable is terminal-local, this function signals an error, |
| 1645 | because such variables cannot have frame-local bindings as well. |
| 1646 | @xref{Multiple Displays}. A few variables that are implemented |
| 1647 | specially in Emacs can be buffer-local, but can never be frame-local. |
| 1648 | |
| 1649 | This command returns @var{variable}. |
| 1650 | @end deffn |
| 1651 | |
| 1652 | Buffer-local bindings take precedence over frame-local bindings. Thus, |
| 1653 | consider a variable @code{foo}: if the current buffer has a buffer-local |
| 1654 | binding for @code{foo}, that binding is active; otherwise, if the |
| 1655 | selected frame has a frame-local binding for @code{foo}, that binding is |
| 1656 | active; otherwise, the default binding of @code{foo} is active. |
| 1657 | |
| 1658 | Here is an example. First we prepare a few bindings for @code{foo}: |
| 1659 | |
| 1660 | @example |
| 1661 | (setq f1 (selected-frame)) |
| 1662 | (make-variable-frame-local 'foo) |
| 1663 | |
| 1664 | ;; @r{Make a buffer-local binding for @code{foo} in @samp{b1}.} |
| 1665 | (set-buffer (get-buffer-create "b1")) |
| 1666 | (make-local-variable 'foo) |
| 1667 | (setq foo '(b 1)) |
| 1668 | |
| 1669 | ;; @r{Make a frame-local binding for @code{foo} in a new frame.} |
| 1670 | ;; @r{Store that frame in @code{f2}.} |
| 1671 | (setq f2 (make-frame)) |
| 1672 | (modify-frame-parameters f2 '((foo . (f 2)))) |
| 1673 | @end example |
| 1674 | |
| 1675 | Now we examine @code{foo} in various contexts. Whenever the |
| 1676 | buffer @samp{b1} is current, its buffer-local binding is in effect, |
| 1677 | regardless of the selected frame: |
| 1678 | |
| 1679 | @example |
| 1680 | (select-frame f1) |
| 1681 | (set-buffer (get-buffer-create "b1")) |
| 1682 | foo |
| 1683 | @result{} (b 1) |
| 1684 | |
| 1685 | (select-frame f2) |
| 1686 | (set-buffer (get-buffer-create "b1")) |
| 1687 | foo |
| 1688 | @result{} (b 1) |
| 1689 | @end example |
| 1690 | |
| 1691 | @noindent |
| 1692 | Otherwise, the frame gets a chance to provide the binding; when frame |
| 1693 | @code{f2} is selected, its frame-local binding is in effect: |
| 1694 | |
| 1695 | @example |
| 1696 | (select-frame f2) |
| 1697 | (set-buffer (get-buffer "*scratch*")) |
| 1698 | foo |
| 1699 | @result{} (f 2) |
| 1700 | @end example |
| 1701 | |
| 1702 | @noindent |
| 1703 | When neither the current buffer nor the selected frame provides |
| 1704 | a binding, the default binding is used: |
| 1705 | |
| 1706 | @example |
| 1707 | (select-frame f1) |
| 1708 | (set-buffer (get-buffer "*scratch*")) |
| 1709 | foo |
| 1710 | @result{} nil |
| 1711 | @end example |
| 1712 | |
| 1713 | @noindent |
| 1714 | When the active binding of a variable is a frame-local binding, setting |
| 1715 | the variable changes that binding. You can observe the result with |
| 1716 | @code{frame-parameters}: |
| 1717 | |
| 1718 | @example |
| 1719 | (select-frame f2) |
| 1720 | (set-buffer (get-buffer "*scratch*")) |
| 1721 | (setq foo 'nobody) |
| 1722 | (assq 'foo (frame-parameters f2)) |
| 1723 | @result{} (foo . nobody) |
| 1724 | @end example |
| 1725 | |
| 1726 | @node Future Local Variables |
| 1727 | @section Possible Future Local Variables |
| 1728 | |
| 1729 | We have considered the idea of bindings that are local to a category |
| 1730 | of frames---for example, all color frames, or all frames with dark |
| 1731 | backgrounds. We have not implemented them because it is not clear that |
| 1732 | this feature is really useful. You can get more or less the same |
| 1733 | results by adding a function to @code{after-make-frame-functions}, set up to |
| 1734 | define a particular frame parameter according to the appropriate |
| 1735 | conditions for each frame. |
| 1736 | |
| 1737 | It would also be possible to implement window-local bindings. We |
| 1738 | don't know of many situations where they would be useful, and it seems |
| 1739 | that indirect buffers (@pxref{Indirect Buffers}) with buffer-local |
| 1740 | bindings offer a way to handle these situations more robustly. |
| 1741 | |
| 1742 | If sufficient application is found for either of these two kinds of |
| 1743 | local bindings, we will provide it in a subsequent Emacs version. |
| 1744 | |
| 1745 | @node File Local Variables |
| 1746 | @section File Local Variables |
| 1747 | |
| 1748 | This section describes the functions and variables that affect |
| 1749 | processing of file local variables. @xref{File variables, , |
| 1750 | Local Variables in Files, emacs, The GNU Emacs Manual}, for basic |
| 1751 | information about file local variables. |
| 1752 | |
| 1753 | @defopt enable-local-variables |
| 1754 | This variable controls whether to process file local variables. A |
| 1755 | value of @code{t} means to process them, querying the user if unsafe |
| 1756 | variables are encountered; @code{nil} means ignore them; anything else |
| 1757 | means to query the user for each file. The default value is @code{t}. |
| 1758 | @end defopt |
| 1759 | |
| 1760 | @defun hack-local-variables &optional mode-only |
| 1761 | This function parses, and binds or evaluates as appropriate, any local |
| 1762 | variables specified by the contents of the current buffer. The variable |
| 1763 | @code{enable-local-variables} has its effect here. However, this |
| 1764 | function does not look for the @samp{mode:} local variable in the |
| 1765 | @w{@samp{-*-}} line. @code{set-auto-mode} does that, also taking |
| 1766 | @code{enable-local-variables} into account (@pxref{Auto Major Mode}). |
| 1767 | |
| 1768 | If the optional argument @var{mode-only} is non-@code{nil}, then all |
| 1769 | this function does is return @code{t} if the @w{@samp{-*-}} line or |
| 1770 | the local variables list specifies a mode and @code{nil} otherwise. |
| 1771 | It does not set the mode nor any other file local variable. |
| 1772 | @end defun |
| 1773 | |
| 1774 | If a file local variable could specify a function that would |
| 1775 | be called later, or an expression that would be executed later, simply |
| 1776 | visiting a file could take over your Emacs. Emacs takes several |
| 1777 | measures to prevent this. |
| 1778 | |
| 1779 | @cindex safe local variable |
| 1780 | You can specify safe values for a variable with a |
| 1781 | @code{safe-local-variable} property. The property has to be |
| 1782 | a function of one argument; any value is safe if the function |
| 1783 | returns non-@code{nil} given that value. Many commonly encountered |
| 1784 | file variables standardly have @code{safe-local-variable} properties, |
| 1785 | including @code{fill-column}, @code{fill-prefix}, and |
| 1786 | @code{indent-tabs-mode}. For boolean-valued variables that are safe, |
| 1787 | use @code{booleanp} as the property value. Lambda expressions should |
| 1788 | be quoted so that @code{describe-variable} can display the predicate. |
| 1789 | |
| 1790 | @defopt safe-local-variable-values |
| 1791 | This variable provides another way to mark some variable values as |
| 1792 | safe. It is a list of cons cells @code{(@var{var} . @var{val})}, |
| 1793 | where @var{var} is a variable name and @var{val} is a value which is |
| 1794 | safe for that variable. |
| 1795 | |
| 1796 | When Emacs asks the user whether or not to obey a set of file local |
| 1797 | variable specifications, the user can choose to mark them as safe. |
| 1798 | Doing so adds those variable/value pairs to |
| 1799 | @code{safe-local-variable-values}, and saves it to the user's custom |
| 1800 | file. |
| 1801 | @end defopt |
| 1802 | |
| 1803 | @defun safe-local-variable-p sym val |
| 1804 | This function returns non-@code{nil} if it is safe to give @var{sym} |
| 1805 | the value @var{val}, based on the above criteria. |
| 1806 | @end defun |
| 1807 | |
| 1808 | @cindex risky local variable |
| 1809 | Some variables are considered @dfn{risky}. A variable whose name |
| 1810 | ends in any of @samp{-command}, @samp{-frame-alist}, @samp{-function}, |
| 1811 | @samp{-functions}, @samp{-hook}, @samp{-hooks}, @samp{-form}, |
| 1812 | @samp{-forms}, @samp{-map}, @samp{-map-alist}, @samp{-mode-alist}, |
| 1813 | @samp{-program}, or @samp{-predicate} is considered risky. The |
| 1814 | variables @samp{font-lock-keywords}, @samp{font-lock-keywords} |
| 1815 | followed by a digit, and @samp{font-lock-syntactic-keywords} are also |
| 1816 | considered risky. Finally, any variable whose name has a |
| 1817 | non-@code{nil} @code{risky-local-variable} property is considered |
| 1818 | risky. |
| 1819 | |
| 1820 | @defun risky-local-variable-p sym |
| 1821 | This function returns non-@code{nil} if @var{sym} is a risky variable, |
| 1822 | based on the above criteria. |
| 1823 | @end defun |
| 1824 | |
| 1825 | If a variable is risky, it will not be entered automatically into |
| 1826 | @code{safe-local-variable-values} as described above. Therefore, |
| 1827 | Emacs will always query before setting a risky variable, unless the |
| 1828 | user explicitly allows the setting by customizing |
| 1829 | @code{safe-local-variable-values} directly. |
| 1830 | |
| 1831 | @defvar ignored-local-variables |
| 1832 | This variable holds a list of variables that should not be given local |
| 1833 | values by files. Any value specified for one of these variables is |
| 1834 | completely ignored. |
| 1835 | @end defvar |
| 1836 | |
| 1837 | The @samp{Eval:} ``variable'' is also a potential loophole, so Emacs |
| 1838 | normally asks for confirmation before handling it. |
| 1839 | |
| 1840 | @defopt enable-local-eval |
| 1841 | This variable controls processing of @samp{Eval:} in @samp{-*-} lines |
| 1842 | or local variables |
| 1843 | lists in files being visited. A value of @code{t} means process them |
| 1844 | unconditionally; @code{nil} means ignore them; anything else means ask |
| 1845 | the user what to do for each file. The default value is @code{maybe}. |
| 1846 | @end defopt |
| 1847 | |
| 1848 | @defopt safe-local-eval-forms |
| 1849 | This variable holds a list of expressions that are safe to |
| 1850 | evaluate when found in the @samp{Eval:} ``variable'' in a file |
| 1851 | local variables list. |
| 1852 | @end defopt |
| 1853 | |
| 1854 | If the expression is a function call and the function has a |
| 1855 | @code{safe-local-eval-function} property, the property value |
| 1856 | determines whether the expression is safe to evaluate. The property |
| 1857 | value can be a predicate to call to test the expression, a list of |
| 1858 | such predicates (it's safe if any predicate succeeds), or @code{t} |
| 1859 | (always safe provided the arguments are constant). |
| 1860 | |
| 1861 | Text properties are also potential loopholes, since their values |
| 1862 | could include functions to call. So Emacs discards all text |
| 1863 | properties from string values specified for file local variables. |
| 1864 | |
| 1865 | @node Variable Aliases |
| 1866 | @section Variable Aliases |
| 1867 | |
| 1868 | It is sometimes useful to make two variables synonyms, so that both |
| 1869 | variables always have the same value, and changing either one also |
| 1870 | changes the other. Whenever you change the name of a |
| 1871 | variable---either because you realize its old name was not well |
| 1872 | chosen, or because its meaning has partly changed---it can be useful |
| 1873 | to keep the old name as an @emph{alias} of the new one for |
| 1874 | compatibility. You can do this with @code{defvaralias}. |
| 1875 | |
| 1876 | @defun defvaralias new-alias base-variable &optional docstring |
| 1877 | This function defines the symbol @var{new-alias} as a variable alias |
| 1878 | for symbol @var{base-variable}. This means that retrieving the value of |
| 1879 | @var{new-alias} returns the value of @var{base-variable}, and changing the |
| 1880 | value of @var{new-alias} changes the value of @var{base-variable}. |
| 1881 | |
| 1882 | If the @var{docstring} argument is non-@code{nil}, it specifies the |
| 1883 | documentation for @var{new-alias}; otherwise, the alias gets the same |
| 1884 | documentation as @var{base-variable} has, if any, unless |
| 1885 | @var{base-variable} is itself an alias, in which case @var{new-alias} gets |
| 1886 | the documentation of the variable at the end of the chain of aliases. |
| 1887 | |
| 1888 | This function returns @var{base-variable}. |
| 1889 | @end defun |
| 1890 | |
| 1891 | Variable aliases are convenient for replacing an old name for a |
| 1892 | variable with a new name. @code{make-obsolete-variable} declares that |
| 1893 | the old name is obsolete and therefore that it may be removed at some |
| 1894 | stage in the future. |
| 1895 | |
| 1896 | @defun make-obsolete-variable obsolete-name current-name &optional when |
| 1897 | This function makes the byte-compiler warn that the variable |
| 1898 | @var{obsolete-name} is obsolete. If @var{current-name} is a symbol, it is |
| 1899 | the variable's new name; then the warning message says to use |
| 1900 | @var{current-name} instead of @var{obsolete-name}. If @var{current-name} |
| 1901 | is a string, this is the message and there is no replacement variable. |
| 1902 | |
| 1903 | If provided, @var{when} should be a string indicating when the |
| 1904 | variable was first made obsolete---for example, a date or a release |
| 1905 | number. |
| 1906 | @end defun |
| 1907 | |
| 1908 | You can make two variables synonyms and declare one obsolete at the |
| 1909 | same time using the macro @code{define-obsolete-variable-alias}. |
| 1910 | |
| 1911 | @defmac define-obsolete-variable-alias obsolete-name current-name &optional when docstring |
| 1912 | This macro marks the variable @var{obsolete-name} as obsolete and also |
| 1913 | makes it an alias for the variable @var{current-name}. It is |
| 1914 | equivalent to the following: |
| 1915 | |
| 1916 | @example |
| 1917 | (defvaralias @var{obsolete-name} @var{current-name} @var{docstring}) |
| 1918 | (make-obsolete-variable @var{obsolete-name} @var{current-name} @var{when}) |
| 1919 | @end example |
| 1920 | @end defmac |
| 1921 | |
| 1922 | @defun indirect-variable variable |
| 1923 | This function returns the variable at the end of the chain of aliases |
| 1924 | of @var{variable}. If @var{variable} is not a symbol, or if @var{variable} is |
| 1925 | not defined as an alias, the function returns @var{variable}. |
| 1926 | |
| 1927 | This function signals a @code{cyclic-variable-indirection} error if |
| 1928 | there is a loop in the chain of symbols. |
| 1929 | @end defun |
| 1930 | |
| 1931 | @example |
| 1932 | (defvaralias 'foo 'bar) |
| 1933 | (indirect-variable 'foo) |
| 1934 | @result{} bar |
| 1935 | (indirect-variable 'bar) |
| 1936 | @result{} bar |
| 1937 | (setq bar 2) |
| 1938 | bar |
| 1939 | @result{} 2 |
| 1940 | @group |
| 1941 | foo |
| 1942 | @result{} 2 |
| 1943 | @end group |
| 1944 | (setq foo 0) |
| 1945 | bar |
| 1946 | @result{} 0 |
| 1947 | foo |
| 1948 | @result{} 0 |
| 1949 | @end example |
| 1950 | |
| 1951 | @node Variables with Restricted Values |
| 1952 | @section Variables with Restricted Values |
| 1953 | |
| 1954 | Ordinary Lisp variables can be assigned any value that is a valid |
| 1955 | Lisp object. However, certain Lisp variables are not defined in Lisp, |
| 1956 | but in C. Most of these variables are defined in the C code using |
| 1957 | @code{DEFVAR_LISP}. Like variables defined in Lisp, these can take on |
| 1958 | any value. However, some variables are defined using |
| 1959 | @code{DEFVAR_INT} or @code{DEFVAR_BOOL}. @xref{Defining Lisp |
| 1960 | variables in C,, Writing Emacs Primitives}, in particular the |
| 1961 | description of functions of the type @code{syms_of_@var{filename}}, |
| 1962 | for a brief discussion of the C implementation. |
| 1963 | |
| 1964 | Variables of type @code{DEFVAR_BOOL} can only take on the values |
| 1965 | @code{nil} or @code{t}. Attempting to assign them any other value |
| 1966 | will set them to @code{t}: |
| 1967 | |
| 1968 | @example |
| 1969 | (let ((display-hourglass 5)) |
| 1970 | display-hourglass) |
| 1971 | @result{} t |
| 1972 | @end example |
| 1973 | |
| 1974 | @defvar byte-boolean-vars |
| 1975 | This variable holds a list of all variables of type @code{DEFVAR_BOOL}. |
| 1976 | @end defvar |
| 1977 | |
| 1978 | Variables of type @code{DEFVAR_INT} can only take on integer values. |
| 1979 | Attempting to assign them any other value will result in an error: |
| 1980 | |
| 1981 | @example |
| 1982 | (setq window-min-height 5.0) |
| 1983 | @error{} Wrong type argument: integerp, 5.0 |
| 1984 | @end example |
| 1985 | |
| 1986 | @ignore |
| 1987 | arch-tag: 5ff62c44-2b51-47bb-99d4-fea5aeec5d3e |
| 1988 | @end ignore |