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