--- /dev/null
+@c -*-texinfo-*-
+@c This is part of the XEmacs Lisp Reference Manual.
+@c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
+@c See the file lispref.texi for copying conditions.
+@setfilename ../../info/variables.info
+@node Variables, Functions and Commands, Control Structures, Top
+@chapter Variables
+@cindex variable
+
+ A @dfn{variable} is a name used in a program to stand for a value.
+Nearly all programming languages have variables of some sort. In the
+text of a Lisp program, variables are written using the syntax for
+symbols.
+
+ In Lisp, unlike most programming languages, programs are represented
+primarily as Lisp objects and only secondarily as text. The Lisp
+objects used for variables are symbols: the symbol name is the variable
+name, and the variable's value is stored in the value cell of the
+symbol. The use of a symbol as a variable is independent of its use as
+a function name. @xref{Symbol Components}.
+
+ The Lisp objects that constitute a Lisp program determine the textual
+form of the program---it is simply the read syntax for those Lisp
+objects. This is why, for example, a variable in a textual Lisp program
+is written using the read syntax for the symbol that represents the
+variable.
+
+@menu
+* Global Variables:: Variable values that exist permanently, everywhere.
+* Constant Variables:: Certain "variables" have values that never change.
+* Local Variables:: Variable values that exist only temporarily.
+* Void Variables:: Symbols that lack values.
+* Defining Variables:: A definition says a symbol is used as a variable.
+* Accessing Variables:: Examining values of variables whose names
+ are known only at run time.
+* Setting Variables:: Storing new values in variables.
+* Variable Scoping:: How Lisp chooses among local and global values.
+* Buffer-Local Variables:: Variable values in effect only in one buffer.
+* Variable Aliases:: Making one variable point to another.
+@end menu
+
+@node Global Variables
+@section Global Variables
+@cindex global variable
+
+ The simplest way to use a variable is @dfn{globally}. This means that
+the variable has just one value at a time, and this value is in effect
+(at least for the moment) throughout the Lisp system. The value remains
+in effect until you specify a new one. When a new value replaces the
+old one, no trace of the old value remains in the variable.
+
+ You specify a value for a symbol with @code{setq}. For example,
+
+@example
+(setq x '(a b))
+@end example
+
+@noindent
+gives the variable @code{x} the value @code{(a b)}. Note that
+@code{setq} does not evaluate its first argument, the name of the
+variable, but it does evaluate the second argument, the new value.
+
+ Once the variable has a value, you can refer to it by using the symbol
+by itself as an expression. Thus,
+
+@example
+@group
+x @result{} (a b)
+@end group
+@end example
+
+@noindent
+assuming the @code{setq} form shown above has already been executed.
+
+ If you do another @code{setq}, the new value replaces the old one:
+
+@example
+@group
+x
+ @result{} (a b)
+@end group
+@group
+(setq x 4)
+ @result{} 4
+@end group
+@group
+x
+ @result{} 4
+@end group
+@end example
+
+@node Constant Variables
+@section Variables That Never Change
+@vindex nil
+@vindex t
+@kindex setting-constant
+
+In XEmacs Lisp, some symbols always evaluate to themselves: the two
+special symbols @code{nil} and @code{t}, as well as @dfn{keyword
+symbols}, that is, symbols whose name begins with the character
+@samp{@code{:}}. These symbols cannot be rebound, nor can their value
+cells be changed. An attempt to change the value of @code{nil} or
+@code{t} signals a @code{setting-constant} error.
+
+@example
+@group
+nil @equiv{} 'nil
+ @result{} nil
+@end group
+@group
+(setq nil 500)
+@error{} Attempt to set constant symbol: nil
+@end group
+@end example
+
+@node Local Variables
+@section Local Variables
+@cindex binding local variables
+@cindex local variables
+@cindex local binding
+@cindex global binding
+
+ Global variables have values that last until explicitly superseded
+with new values. Sometimes it is useful to create variable values that
+exist temporarily---only while within a certain part of the program.
+These values are called @dfn{local}, and the variables so used are
+called @dfn{local variables}.
+
+ For example, when a function is called, its argument variables receive
+new local values that last until the function exits. The @code{let}
+special form explicitly establishes new local values for specified
+variables; these last until exit from the @code{let} form.
+
+@cindex shadowing of variables
+ Establishing a local value saves away the previous value (or lack of
+one) of the variable. When the life span of the local value is over,
+the previous value is restored. In the mean time, we say that the
+previous value is @dfn{shadowed} and @dfn{not visible}. Both global and
+local values may be shadowed (@pxref{Scope}).
+
+ If you set a variable (such as with @code{setq}) while it is local,
+this replaces the local value; it does not alter the global value, or
+previous local values that are shadowed. To model this behavior, we
+speak of a @dfn{local binding} of the variable as well as a local value.
+
+ The local binding is a conceptual place that holds a local value.
+Entry to a function, or a special form such as @code{let}, creates the
+local binding; exit from the function or from the @code{let} removes the
+local binding. As long as the local binding lasts, the variable's value
+is stored within it. Use of @code{setq} or @code{set} while there is a
+local binding stores a different value into the local binding; it does
+not create a new binding.
+
+ We also speak of the @dfn{global binding}, which is where
+(conceptually) the global value is kept.
+
+@cindex current binding
+ A variable can have more than one local binding at a time (for
+example, if there are nested @code{let} forms that bind it). In such a
+case, the most recently created local binding that still exists is the
+@dfn{current binding} of the variable. (This is called @dfn{dynamic
+scoping}; see @ref{Variable Scoping}.) If there are no local bindings,
+the variable's global binding is its current binding. We also call the
+current binding the @dfn{most-local existing binding}, for emphasis.
+Ordinary evaluation of a symbol always returns the value of its current
+binding.
+
+ The special forms @code{let} and @code{let*} exist to create
+local bindings.
+
+@defspec let (bindings@dots{}) forms@dots{}
+This special form binds variables according to @var{bindings} and then
+evaluates all of the @var{forms} in textual order. The @code{let}-form
+returns the value of the last form in @var{forms}.
+
+Each of the @var{bindings} is either @w{(i) a} symbol, in which case
+that symbol is bound to @code{nil}; or @w{(ii) a} list of the form
+@code{(@var{symbol} @var{value-form})}, in which case @var{symbol} is
+bound to the result of evaluating @var{value-form}. If @var{value-form}
+is omitted, @code{nil} is used.
+
+All of the @var{value-form}s in @var{bindings} are evaluated in the
+order they appear and @emph{before} any of the symbols are bound. Here
+is an example of this: @code{Z} is bound to the old value of @code{Y},
+which is 2, not the new value, 1.
+
+@example
+@group
+(setq Y 2)
+ @result{} 2
+@end group
+@group
+(let ((Y 1)
+ (Z Y))
+ (list Y Z))
+ @result{} (1 2)
+@end group
+@end example
+@end defspec
+
+@defspec let* (bindings@dots{}) forms@dots{}
+This special form is like @code{let}, but it binds each variable right
+after computing its local value, before computing the local value for
+the next variable. Therefore, an expression in @var{bindings} can
+reasonably refer to the preceding symbols bound in this @code{let*}
+form. Compare the following example with the example above for
+@code{let}.
+
+@example
+@group
+(setq Y 2)
+ @result{} 2
+@end group
+@group
+(let* ((Y 1)
+ (Z Y)) ; @r{Use the just-established value of @code{Y}.}
+ (list Y Z))
+ @result{} (1 1)
+@end group
+@end example
+@end defspec
+
+ Here is a complete list of the other facilities that create local
+bindings:
+
+@itemize @bullet
+@item
+Function calls (@pxref{Functions and Commands}).
+
+@item
+Macro calls (@pxref{Macros}).
+
+@item
+@code{condition-case} (@pxref{Errors}).
+@end itemize
+
+ Variables can also have buffer-local bindings (@pxref{Buffer-Local
+Variables}). These kinds of bindings work somewhat like ordinary local
+bindings, but they are localized depending on ``where'' you are in
+Emacs, rather than localized in time.
+
+@defvar max-specpdl-size
+@cindex variable limit error
+@cindex evaluation error
+@cindex infinite recursion
+ This variable defines the limit on the total number of local variable
+bindings and @code{unwind-protect} cleanups (@pxref{Nonlocal Exits})
+that are allowed before signaling an error (with data @code{"Variable
+binding depth exceeds max-specpdl-size"}).
+
+ This limit, with the associated error when it is exceeded, is one way
+that Lisp avoids infinite recursion on an ill-defined function.
+
+ The default value is 3000.
+
+ @code{max-lisp-eval-depth} provides another limit on depth of nesting.
+@xref{Eval}.
+@end defvar
+
+@node Void Variables
+@section When a Variable is ``Void''
+@kindex void-variable
+@cindex void variable
+
+ If you have never given a symbol any value as a global variable, we
+say that that symbol's global value is @dfn{void}. In other words, the
+symbol's value cell does not have any Lisp object in it. If you try to
+evaluate the symbol, you get a @code{void-variable} error rather than
+a value.
+
+ Note that a value of @code{nil} is not the same as void. The symbol
+@code{nil} is a Lisp object and can be the value of a variable just as any
+other object can be; but it is @emph{a value}. A void variable does not
+have any value.
+
+ After you have given a variable a value, you can make it void once more
+using @code{makunbound}.
+
+@defun makunbound symbol
+This function makes the current binding of @var{symbol} void.
+Subsequent attempts to use this symbol's value as a variable will signal
+the error @code{void-variable}, unless or until you set it again.
+
+@code{makunbound} returns @var{symbol}.
+
+@example
+@group
+(makunbound 'x) ; @r{Make the global value}
+ ; @r{of @code{x} void.}
+ @result{} x
+@end group
+@group
+x
+@error{} Symbol's value as variable is void: x
+@end group
+@end example
+
+If @var{symbol} is locally bound, @code{makunbound} affects the most
+local existing binding. This is the only way a symbol can have a void
+local binding, since all the constructs that create local bindings
+create them with values. In this case, the voidness lasts at most as
+long as the binding does; when the binding is removed due to exit from
+the construct that made it, the previous or global binding is reexposed
+as usual, and the variable is no longer void unless the newly reexposed
+binding was void all along.
+
+@smallexample
+@group
+(setq x 1) ; @r{Put a value in the global binding.}
+ @result{} 1
+(let ((x 2)) ; @r{Locally bind it.}
+ (makunbound 'x) ; @r{Void the local binding.}
+ x)
+@error{} Symbol's value as variable is void: x
+@end group
+@group
+x ; @r{The global binding is unchanged.}
+ @result{} 1
+
+(let ((x 2)) ; @r{Locally bind it.}
+ (let ((x 3)) ; @r{And again.}
+ (makunbound 'x) ; @r{Void the innermost-local binding.}
+ x)) ; @r{And refer: it's void.}
+@error{} Symbol's value as variable is void: x
+@end group
+
+@group
+(let ((x 2))
+ (let ((x 3))
+ (makunbound 'x)) ; @r{Void inner binding, then remove it.}
+ x) ; @r{Now outer @code{let} binding is visible.}
+ @result{} 2
+@end group
+@end smallexample
+@end defun
+
+ A variable that has been made void with @code{makunbound} is
+indistinguishable from one that has never received a value and has
+always been void.
+
+ You can use the function @code{boundp} to test whether a variable is
+currently void.
+
+@defun boundp variable
+@code{boundp} returns @code{t} if @var{variable} (a symbol) is not void;
+more precisely, if its current binding is not void. It returns
+@code{nil} otherwise.
+
+@smallexample
+@group
+(boundp 'abracadabra) ; @r{Starts out void.}
+ @result{} nil
+@end group
+@group
+(let ((abracadabra 5)) ; @r{Locally bind it.}
+ (boundp 'abracadabra))
+ @result{} t
+@end group
+@group
+(boundp 'abracadabra) ; @r{Still globally void.}
+ @result{} nil
+@end group
+@group
+(setq abracadabra 5) ; @r{Make it globally nonvoid.}
+ @result{} 5
+@end group
+@group
+(boundp 'abracadabra)
+ @result{} t
+@end group
+@end smallexample
+@end defun
+
+@node Defining Variables
+@section Defining Global Variables
+@cindex variable definition
+
+ You may announce your intention to use a symbol as a global variable
+with a @dfn{variable definition}: a special form, either @code{defconst}
+or @code{defvar}.
+
+ In XEmacs Lisp, definitions serve three purposes. First, they inform
+people who read the code that certain symbols are @emph{intended} to be
+used a certain way (as variables). Second, they inform the Lisp system
+of these things, supplying a value and documentation. Third, they
+provide information to utilities such as @code{etags} and
+@code{make-docfile}, which create data bases of the functions and
+variables in a program.
+
+ The difference between @code{defconst} and @code{defvar} is primarily
+a matter of intent, serving to inform human readers of whether programs
+will change the variable. XEmacs Lisp does not restrict the ways in
+which a variable can be used based on @code{defconst} or @code{defvar}
+declarations. However, it does make a difference for initialization:
+@code{defconst} unconditionally initializes the variable, while
+@code{defvar} initializes it only if it is void.
+
+ One would expect user option variables to be defined with
+@code{defconst}, since programs do not change them. Unfortunately, this
+has bad results if the definition is in a library that is not preloaded:
+@code{defconst} would override any prior value when the library is
+loaded. Users would like to be able to set user options in their init
+files, and override the default values given in the definitions. For
+this reason, user options must be defined with @code{defvar}.
+
+@defspec defvar symbol [value [doc-string]]
+This special form defines @var{symbol} as a value and initializes it.
+The definition informs a person reading your code that @var{symbol} is
+used as a variable that programs are likely to set or change. It is
+also used for all user option variables except in the preloaded parts of
+XEmacs. Note that @var{symbol} is not evaluated; the symbol to be
+defined must appear explicitly in the @code{defvar}.
+
+If @var{symbol} already has a value (i.e., it is not void), @var{value}
+is not even evaluated, and @var{symbol}'s value remains unchanged. If
+@var{symbol} is void and @var{value} is specified, @code{defvar}
+evaluates it and sets @var{symbol} to the result. (If @var{value} is
+omitted, the value of @var{symbol} is not changed in any case.)
+
+When you evaluate a top-level @code{defvar} form with @kbd{C-M-x} in
+Emacs Lisp mode (@code{eval-defun}), a special feature of
+@code{eval-defun} evaluates it as a @code{defconst}. The purpose of
+this is to make sure the variable's value is reinitialized, when you ask
+for it specifically.
+
+If @var{symbol} has a buffer-local binding in the current buffer,
+@code{defvar} sets the default value, not the local value.
+@xref{Buffer-Local Variables}.
+
+If the @var{doc-string} argument appears, it specifies the documentation
+for the variable. (This opportunity to specify documentation is one of
+the main benefits of defining the variable.) The documentation is
+stored in the symbol's @code{variable-documentation} property. The
+XEmacs help functions (@pxref{Documentation}) look for this property.
+
+If the first character of @var{doc-string} is @samp{*}, it means that
+this variable is considered a user option. This lets users set the
+variable conveniently using the commands @code{set-variable} and
+@code{edit-options}.
+
+For example, this form defines @code{foo} but does not set its value:
+
+@example
+@group
+(defvar foo)
+ @result{} foo
+@end group
+@end example
+
+The following example sets the value of @code{bar} to @code{23}, and
+gives it a documentation string:
+
+@example
+@group
+(defvar bar 23
+ "The normal weight of a bar.")
+ @result{} bar
+@end group
+@end example
+
+The following form changes the documentation string for @code{bar},
+making it a user option, but does not change the value, since @code{bar}
+already has a value. (The addition @code{(1+ 23)} is not even
+performed.)
+
+@example
+@group
+(defvar bar (1+ 23)
+ "*The normal weight of a bar.")
+ @result{} bar
+@end group
+@group
+bar
+ @result{} 23
+@end group
+@end example
+
+Here is an equivalent expression for the @code{defvar} special form:
+
+@example
+@group
+(defvar @var{symbol} @var{value} @var{doc-string})
+@equiv{}
+(progn
+ (if (not (boundp '@var{symbol}))
+ (setq @var{symbol} @var{value}))
+ (put '@var{symbol} 'variable-documentation '@var{doc-string})
+ '@var{symbol})
+@end group
+@end example
+
+The @code{defvar} form returns @var{symbol}, but it is normally used
+at top level in a file where its value does not matter.
+@end defspec
+
+@defspec defconst symbol [value [doc-string]]
+This special form defines @var{symbol} as a value and initializes it.
+It informs a person reading your code that @var{symbol} has a global
+value, established here, that will not normally be changed or locally
+bound by the execution of the program. The user, however, may be
+welcome to change it. Note that @var{symbol} is not evaluated; the
+symbol to be defined must appear explicitly in the @code{defconst}.
+
+@code{defconst} always evaluates @var{value} and sets the global value
+of @var{symbol} to the result, provided @var{value} is given. If
+@var{symbol} has a buffer-local binding in the current buffer,
+@code{defconst} sets the default value, not the local value.
+
+@strong{Please note:} Don't use @code{defconst} for user option
+variables in libraries that are not standardly preloaded. The user
+should be able to specify a value for such a variable in the
+@file{.emacs} file, so that it will be in effect if and when the library
+is loaded later.
+
+Here, @code{pi} is a constant that presumably ought not to be changed
+by anyone (attempts by the Indiana State Legislature notwithstanding).
+As the second form illustrates, however, this is only advisory.
+
+@example
+@group
+(defconst pi 3.1415 "Pi to five places.")
+ @result{} pi
+@end group
+@group
+(setq pi 3)
+ @result{} pi
+@end group
+@group
+pi
+ @result{} 3
+@end group
+@end example
+@end defspec
+
+@defun user-variable-p variable
+@cindex user option
+This function returns @code{t} if @var{variable} is a user option---a
+variable intended to be set by the user for customization---and
+@code{nil} otherwise. (Variables other than user options exist for the
+internal purposes of Lisp programs, and users need not know about them.)
+
+User option variables are distinguished from other variables by the
+first character of the @code{variable-documentation} property. If the
+property exists and is a string, and its first character is @samp{*},
+then the variable is a user option.
+@end defun
+
+ If a user option variable has a @code{variable-interactive} property,
+the @code{set-variable} command uses that value to control reading the
+new value for the variable. The property's value is used as if it were
+the argument to @code{interactive}.
+
+ @strong{Warning:} If the @code{defconst} and @code{defvar} special
+forms are used while the variable has a local binding, they set the
+local binding's value; the global binding is not changed. This is not
+what we really want. To prevent it, use these special forms at top
+level in a file, where normally no local binding is in effect, and make
+sure to load the file before making a local binding for the variable.
+
+@node Accessing Variables
+@section Accessing Variable Values
+
+ The usual way to reference a variable is to write the symbol which
+names it (@pxref{Symbol Forms}). This requires you to specify the
+variable name when you write the program. Usually that is exactly what
+you want to do. Occasionally you need to choose at run time which
+variable to reference; then you can use @code{symbol-value}.
+
+@defun symbol-value symbol
+This function returns the value of @var{symbol}. This is the value in
+the innermost local binding of the symbol, or its global value if it
+has no local bindings.
+
+@example
+@group
+(setq abracadabra 5)
+ @result{} 5
+@end group
+@group
+(setq foo 9)
+ @result{} 9
+@end group
+
+@group
+;; @r{Here the symbol @code{abracadabra}}
+;; @r{is the symbol whose value is examined.}
+(let ((abracadabra 'foo))
+ (symbol-value 'abracadabra))
+ @result{} foo
+@end group
+
+@group
+;; @r{Here the value of @code{abracadabra},}
+;; @r{which is @code{foo},}
+;; @r{is the symbol whose value is examined.}
+(let ((abracadabra 'foo))
+ (symbol-value abracadabra))
+ @result{} 9
+@end group
+
+@group
+(symbol-value 'abracadabra)
+ @result{} 5
+@end group
+@end example
+
+A @code{void-variable} error is signaled if @var{symbol} has neither a
+local binding nor a global value.
+@end defun
+
+@node Setting Variables
+@section How to Alter a Variable Value
+
+ The usual way to change the value of a variable is with the special
+form @code{setq}. When you need to compute the choice of variable at
+run time, use the function @code{set}.
+
+@defspec setq [symbol form]@dots{}
+This special form is the most common method of changing a variable's
+value. Each @var{symbol} is given a new value, which is the result of
+evaluating the corresponding @var{form}. The most-local existing
+binding of the symbol is changed.
+
+@code{setq} does not evaluate @var{symbol}; it sets the symbol that you
+write. We say that this argument is @dfn{automatically quoted}. The
+@samp{q} in @code{setq} stands for ``quoted.''
+
+The value of the @code{setq} form is the value of the last @var{form}.
+
+@example
+@group
+(setq x (1+ 2))
+ @result{} 3
+@end group
+x ; @r{@code{x} now has a global value.}
+ @result{} 3
+@group
+(let ((x 5))
+ (setq x 6) ; @r{The local binding of @code{x} is set.}
+ x)
+ @result{} 6
+@end group
+x ; @r{The global value is unchanged.}
+ @result{} 3
+@end example
+
+Note that the first @var{form} is evaluated, then the first
+@var{symbol} is set, then the second @var{form} is evaluated, then the
+second @var{symbol} is set, and so on:
+
+@example
+@group
+(setq x 10 ; @r{Notice that @code{x} is set before}
+ y (1+ x)) ; @r{the value of @code{y} is computed.}
+ @result{} 11
+@end group
+@end example
+@end defspec
+
+@defun set symbol value
+This function sets @var{symbol}'s value to @var{value}, then returns
+@var{value}. Since @code{set} is a function, the expression written for
+@var{symbol} is evaluated to obtain the symbol to set.
+
+The most-local existing binding of the variable is the binding that is
+set; shadowed bindings are not affected.
+
+@example
+@group
+(set one 1)
+@error{} Symbol's value as variable is void: one
+@end group
+@group
+(set 'one 1)
+ @result{} 1
+@end group
+@group
+(set 'two 'one)
+ @result{} one
+@end group
+@group
+(set two 2) ; @r{@code{two} evaluates to symbol @code{one}.}
+ @result{} 2
+@end group
+@group
+one ; @r{So it is @code{one} that was set.}
+ @result{} 2
+(let ((one 1)) ; @r{This binding of @code{one} is set,}
+ (set 'one 3) ; @r{not the global value.}
+ one)
+ @result{} 3
+@end group
+@group
+one
+ @result{} 2
+@end group
+@end example
+
+If @var{symbol} is not actually a symbol, a @code{wrong-type-argument}
+error is signaled.
+
+@example
+(set '(x y) 'z)
+@error{} Wrong type argument: symbolp, (x y)
+@end example
+
+Logically speaking, @code{set} is a more fundamental primitive than
+@code{setq}. Any use of @code{setq} can be trivially rewritten to use
+@code{set}; @code{setq} could even be defined as a macro, given the
+availability of @code{set}. However, @code{set} itself is rarely used;
+beginners hardly need to know about it. It is useful only for choosing
+at run time which variable to set. For example, the command
+@code{set-variable}, which reads a variable name from the user and then
+sets the variable, needs to use @code{set}.
+
+@cindex CL note---@code{set} local
+@quotation
+@b{Common Lisp note:} In Common Lisp, @code{set} always changes the
+symbol's special value, ignoring any lexical bindings. In XEmacs Lisp,
+all variables and all bindings are (in effect) special, so @code{set}
+always affects the most local existing binding.
+@end quotation
+@end defun
+
+ One other function for setting a variable is designed to add
+an element to a list if it is not already present in the list.
+
+@defun add-to-list symbol element
+This function sets the variable @var{symbol} by consing @var{element}
+onto the old value, if @var{element} is not already a member of that
+value. It returns the resulting list, whether updated or not. The
+value of @var{symbol} had better be a list already before the call.
+
+The argument @var{symbol} is not implicitly quoted; @code{add-to-list}
+is an ordinary function, like @code{set} and unlike @code{setq}. Quote
+the argument yourself if that is what you want.
+
+Here's a scenario showing how to use @code{add-to-list}:
+
+@example
+(setq foo '(a b))
+ @result{} (a b)
+
+(add-to-list 'foo 'c) ;; @r{Add @code{c}.}
+ @result{} (c a b)
+
+(add-to-list 'foo 'b) ;; @r{No effect.}
+ @result{} (c a b)
+
+foo ;; @r{@code{foo} was changed.}
+ @result{} (c a b)
+@end example
+@end defun
+
+ An equivalent expression for @code{(add-to-list '@var{var}
+@var{value})} is this:
+
+@example
+(or (member @var{value} @var{var})
+ (setq @var{var} (cons @var{value} @var{var})))
+@end example
+
+@node Variable Scoping
+@section Scoping Rules for Variable Bindings
+
+ A given symbol @code{foo} may have several local variable bindings,
+established at different places in the Lisp program, as well as a global
+binding. The most recently established binding takes precedence over
+the others.
+
+@cindex scope
+@cindex extent
+@cindex dynamic scoping
+ Local bindings in XEmacs Lisp have @dfn{indefinite scope} and
+@dfn{dynamic extent}. @dfn{Scope} refers to @emph{where} textually in
+the source code the binding can be accessed. Indefinite scope means
+that any part of the program can potentially access the variable
+binding. @dfn{Extent} refers to @emph{when}, as the program is
+executing, the binding exists. Dynamic extent means that the binding
+lasts as long as the activation of the construct that established it.
+
+ The combination of dynamic extent and indefinite scope is called
+@dfn{dynamic scoping}. By contrast, most programming languages use
+@dfn{lexical scoping}, in which references to a local variable must be
+located textually within the function or block that binds the variable.
+
+@cindex CL note---special variables
+@quotation
+@b{Common Lisp note:} Variables declared ``special'' in Common Lisp
+are dynamically scoped, like variables in XEmacs Lisp.
+@end quotation
+
+@menu
+* Scope:: Scope means where in the program a value is visible.
+ Comparison with other languages.
+* Extent:: Extent means how long in time a value exists.
+* Impl of Scope:: Two ways to implement dynamic scoping.
+* Using Scoping:: How to use dynamic scoping carefully and avoid problems.
+@end menu
+
+@node Scope
+@subsection Scope
+
+ XEmacs Lisp uses @dfn{indefinite scope} for local variable bindings.
+This means that any function anywhere in the program text might access a
+given binding of a variable. Consider the following function
+definitions:
+
+@example
+@group
+(defun binder (x) ; @r{@code{x} is bound in @code{binder}.}
+ (foo 5)) ; @r{@code{foo} is some other function.}
+@end group
+
+@group
+(defun user () ; @r{@code{x} is used in @code{user}.}
+ (list x))
+@end group
+@end example
+
+ In a lexically scoped language, the binding of @code{x} in
+@code{binder} would never be accessible in @code{user}, because
+@code{user} is not textually contained within the function
+@code{binder}. However, in dynamically scoped XEmacs Lisp, @code{user}
+may or may not refer to the binding of @code{x} established in
+@code{binder}, depending on circumstances:
+
+@itemize @bullet
+@item
+If we call @code{user} directly without calling @code{binder} at all,
+then whatever binding of @code{x} is found, it cannot come from
+@code{binder}.
+
+@item
+If we define @code{foo} as follows and call @code{binder}, then the
+binding made in @code{binder} will be seen in @code{user}:
+
+@example
+@group
+(defun foo (lose)
+ (user))
+@end group
+@end example
+
+@item
+If we define @code{foo} as follows and call @code{binder}, then the
+binding made in @code{binder} @emph{will not} be seen in @code{user}:
+
+@example
+(defun foo (x)
+ (user))
+@end example
+
+@noindent
+Here, when @code{foo} is called by @code{binder}, it binds @code{x}.
+(The binding in @code{foo} is said to @dfn{shadow} the one made in
+@code{binder}.) Therefore, @code{user} will access the @code{x} bound
+by @code{foo} instead of the one bound by @code{binder}.
+@end itemize
+
+@node Extent
+@subsection Extent
+
+ @dfn{Extent} refers to the time during program execution that a
+variable name is valid. In XEmacs Lisp, a variable is valid only while
+the form that bound it is executing. This is called @dfn{dynamic
+extent}. ``Local'' or ``automatic'' variables in most languages,
+including C and Pascal, have dynamic extent.
+
+ One alternative to dynamic extent is @dfn{indefinite extent}. This
+means that a variable binding can live on past the exit from the form
+that made the binding. Common Lisp and Scheme, for example, support
+this, but XEmacs Lisp does not.
+
+ To illustrate this, the function below, @code{make-add}, returns a
+function that purports to add @var{n} to its own argument @var{m}.
+This would work in Common Lisp, but it does not work as intended in
+XEmacs Lisp, because after the call to @code{make-add} exits, the
+variable @code{n} is no longer bound to the actual argument 2.
+
+@example
+(defun make-add (n)
+ (function (lambda (m) (+ n m)))) ; @r{Return a function.}
+ @result{} make-add
+(fset 'add2 (make-add 2)) ; @r{Define function @code{add2}}
+ ; @r{with @code{(make-add 2)}.}
+ @result{} (lambda (m) (+ n m))
+(add2 4) ; @r{Try to add 2 to 4.}
+@error{} Symbol's value as variable is void: n
+@end example
+
+@cindex closures not available
+ Some Lisp dialects have ``closures'', objects that are like functions
+but record additional variable bindings. XEmacs Lisp does not have
+closures.
+
+@node Impl of Scope
+@subsection Implementation of Dynamic Scoping
+@cindex deep binding
+
+ A simple sample implementation (which is not how XEmacs Lisp actually
+works) may help you understand dynamic binding. This technique is
+called @dfn{deep binding} and was used in early Lisp systems.
+
+ Suppose there is a stack of bindings: variable-value pairs. At entry
+to a function or to a @code{let} form, we can push bindings on the stack
+for the arguments or local variables created there. We can pop those
+bindings from the stack at exit from the binding construct.
+
+ We can find the value of a variable by searching the stack from top to
+bottom for a binding for that variable; the value from that binding is
+the value of the variable. To set the variable, we search for the
+current binding, then store the new value into that binding.
+
+ As you can see, a function's bindings remain in effect as long as it
+continues execution, even during its calls to other functions. That is
+why we say the extent of the binding is dynamic. And any other function
+can refer to the bindings, if it uses the same variables while the
+bindings are in effect. That is why we say the scope is indefinite.
+
+@cindex shallow binding
+ The actual implementation of variable scoping in XEmacs Lisp uses a
+technique called @dfn{shallow binding}. Each variable has a standard
+place in which its current value is always found---the value cell of the
+symbol.
+
+ In shallow binding, setting the variable works by storing a value in
+the value cell. Creating a new binding works by pushing the old value
+(belonging to a previous binding) on a stack, and storing the local value
+in the value cell. Eliminating a binding works by popping the old value
+off the stack, into the value cell.
+
+ We use shallow binding because it has the same results as deep
+binding, but runs faster, since there is never a need to search for a
+binding.
+
+@node Using Scoping
+@subsection Proper Use of Dynamic Scoping
+
+ Binding a variable in one function and using it in another is a
+powerful technique, but if used without restraint, it can make programs
+hard to understand. There are two clean ways to use this technique:
+
+@itemize @bullet
+@item
+Use or bind the variable only in a few related functions, written close
+together in one file. Such a variable is used for communication within
+one program.
+
+You should write comments to inform other programmers that they can see
+all uses of the variable before them, and to advise them not to add uses
+elsewhere.
+
+@item
+Give the variable a well-defined, documented meaning, and make all
+appropriate functions refer to it (but not bind it or set it) wherever
+that meaning is relevant. For example, the variable
+@code{case-fold-search} is defined as ``non-@code{nil} means ignore case
+when searching''; various search and replace functions refer to it
+directly or through their subroutines, but do not bind or set it.
+
+Then you can bind the variable in other programs, knowing reliably what
+the effect will be.
+@end itemize
+
+ In either case, you should define the variable with @code{defvar}.
+This helps other people understand your program by telling them to look
+for inter-function usage. It also avoids a warning from the byte
+compiler. Choose the variable's name to avoid name conflicts---don't
+use short names like @code{x}.
+
+@node Buffer-Local Variables
+@section Buffer-Local Variables
+@cindex variables, buffer-local
+@cindex buffer-local variables
+
+ Global and local variable bindings are found in most programming
+languages in one form or another. XEmacs also supports another, unusual
+kind of variable binding: @dfn{buffer-local} bindings, which apply only
+to one buffer. XEmacs Lisp is meant for programming editing commands,
+and having different values for a variable in different buffers is an
+important customization method.
+
+@menu
+* Intro to Buffer-Local:: Introduction and concepts.
+* Creating Buffer-Local:: Creating and destroying buffer-local bindings.
+* Default Value:: The default value is seen in buffers
+ that don't have their own local values.
+@end menu
+
+@node Intro to Buffer-Local
+@subsection Introduction to Buffer-Local Variables
+
+ A buffer-local variable has a buffer-local binding associated with a
+particular buffer. The binding is in effect when that buffer is
+current; otherwise, it is not in effect. If you set the variable while
+a buffer-local binding is in effect, the new value goes in that binding,
+so the global binding is unchanged; this means that the change is
+visible in that buffer alone.
+
+ A variable may have buffer-local bindings in some buffers but not in
+others. The global binding is shared by all the buffers that don't have
+their own bindings. Thus, if you set the variable in a buffer that does
+not have a buffer-local binding for it, the new value is visible in all
+buffers except those with buffer-local bindings. (Here we are assuming
+that there are no @code{let}-style local bindings to complicate the issue.)
+
+ The most common use of buffer-local bindings is for major modes to change
+variables that control the behavior of commands. For example, C mode and
+Lisp mode both set the variable @code{paragraph-start} to specify that only
+blank lines separate paragraphs. They do this by making the variable
+buffer-local in the buffer that is being put into C mode or Lisp mode, and
+then setting it to the new value for that mode.
+
+ The usual way to make a buffer-local binding is with
+@code{make-local-variable}, which is what major mode commands use. This
+affects just the current buffer; all other buffers (including those yet to
+be created) continue to share the global value.
+
+@cindex automatically buffer-local
+ A more powerful operation is to mark the variable as
+@dfn{automatically buffer-local} by calling
+@code{make-variable-buffer-local}. You can think of this as making the
+variable local in all buffers, even those yet to be created. More
+precisely, the effect is that setting the variable automatically makes
+the variable local to the current buffer if it is not already so. All
+buffers start out by sharing the global value of the variable as usual,
+but any @code{setq} creates a buffer-local binding for the current
+buffer. The new value is stored in the buffer-local binding, leaving
+the (default) global binding untouched. The global value can no longer
+be changed with @code{setq}; you need to use @code{setq-default} to do
+that.
+
+@ignore
+Section about not changing buffers during let bindings. Mly fixed
+this for XEmacs.
+@end ignore
+ Local variables in a file you edit are also represented by
+buffer-local bindings for the buffer that holds the file within XEmacs.
+@xref{Auto Major Mode}.
+
+@node Creating Buffer-Local
+@subsection Creating and Deleting Buffer-Local Bindings
+
+@deffn Command make-local-variable variable
+This function creates a buffer-local binding in the current buffer for
+@var{variable} (a symbol). Other buffers are not affected. The value
+returned is @var{variable}.
+
+@c Emacs 19 feature
+The buffer-local value of @var{variable} starts out as the same value
+@var{variable} previously had. If @var{variable} was void, it remains
+void.
+
+@example
+@group
+;; @r{In buffer @samp{b1}:}
+(setq foo 5) ; @r{Affects all buffers.}
+ @result{} 5
+@end group
+@group
+(make-local-variable 'foo) ; @r{Now it is local in @samp{b1}.}
+ @result{} foo
+@end group
+@group
+foo ; @r{That did not change}
+ @result{} 5 ; @r{the value.}
+@end group
+@group
+(setq foo 6) ; @r{Change the value}
+ @result{} 6 ; @r{in @samp{b1}.}
+@end group
+@group
+foo
+ @result{} 6
+@end group
+
+@group
+;; @r{In buffer @samp{b2}, the value hasn't changed.}
+(save-excursion
+ (set-buffer "b2")
+ foo)
+ @result{} 5
+@end group
+@end example
+
+Making a variable buffer-local within a @code{let}-binding for that
+variable does not work. This is because @code{let} does not distinguish
+between different kinds of bindings; it knows only which variable the
+binding was made for.
+
+@strong{Please note:} do not use @code{make-local-variable} for a hook
+variable. Instead, use @code{make-local-hook}. @xref{Hooks}.
+@end deffn
+
+@deffn Command make-variable-buffer-local variable
+This function marks @var{variable} (a symbol) automatically
+buffer-local, so that any subsequent attempt to set it will make it
+local to the current buffer at the time.
+
+The value returned is @var{variable}.
+@end deffn
+
+@defun local-variable-p variable buffer &optional after-set
+This returns @code{t} if @var{variable} is buffer-local in buffer
+@var{buffer}; else @code{nil}.
+
+If optional third arg @var{after-set} is non-@code{nil}, return @code{t}
+if @var{symbol} would be buffer-local after it is set, regardless of
+whether it is so presently.
+
+A @code{nil} value for @var{buffer} is @emph{not} the same as
+@code{(current-buffer)}, but means "no buffer". Specifically:
+
+If @var{buffer} is @code{nil} and @var{after-set} is @code{nil}, a
+return value of @code{t} indicates that the variable is one of the
+special built-in variables that is always buffer-local. (This includes
+@code{buffer-file-name}, @code{buffer-read-only},
+@code{buffer-undo-list}, and others.)
+
+If @var{buffer} is @code{nil} and @var{after-set} is @code{t}, a return
+value of @code{t} indicates that the variable has had
+@code{make-variable-buffer-local} applied to it.
+@end defun
+
+@defun buffer-local-variables &optional buffer
+This function returns a list describing the buffer-local variables in
+buffer @var{buffer}. It returns an association list (@pxref{Association
+Lists}) in which each association contains one buffer-local variable and
+its value. When a buffer-local variable is void in @var{buffer}, then
+it appears directly in the resulting list. If @var{buffer} is omitted,
+the current buffer is used.
+
+@example
+@group
+(make-local-variable 'foobar)
+(makunbound 'foobar)
+(make-local-variable 'bind-me)
+(setq bind-me 69)
+@end group
+(setq lcl (buffer-local-variables))
+ ;; @r{First, built-in variables local in all buffers:}
+@result{} ((mark-active . nil)
+ (buffer-undo-list nil)
+ (mode-name . "Fundamental")
+ @dots{}
+@group
+ ;; @r{Next, non-built-in local variables.}
+ ;; @r{This one is local and void:}
+ foobar
+ ;; @r{This one is local and nonvoid:}
+ (bind-me . 69))
+@end group
+@end example
+
+Note that storing new values into the @sc{cdr}s of cons cells in this
+list does @emph{not} change the local values of the variables.
+@end defun
+
+@deffn Command kill-local-variable variable
+This function deletes the buffer-local binding (if any) for
+@var{variable} (a symbol) in the current buffer. As a result, the
+global (default) binding of @var{variable} becomes visible in this
+buffer. Usually this results in a change in the value of
+@var{variable}, since the global value is usually different from the
+buffer-local value just eliminated.
+
+If you kill the local binding of a variable that automatically becomes
+local when set, this makes the global value visible in the current
+buffer. However, if you set the variable again, that will once again
+create a local binding for it.
+
+@code{kill-local-variable} returns @var{variable}.
+
+This function is a command because it is sometimes useful to kill one
+buffer-local variable interactively, just as it is useful to create
+buffer-local variables interactively.
+@end deffn
+
+@defun kill-all-local-variables
+This function eliminates all the buffer-local variable bindings of the
+current buffer except for variables marked as ``permanent''. As a
+result, the buffer will see the default values of most variables.
+
+This function also resets certain other information pertaining to the
+buffer: it sets the local keymap to @code{nil}, the syntax table to the
+value of @code{standard-syntax-table}, and the abbrev table to the value
+of @code{fundamental-mode-abbrev-table}.
+
+Every major mode command begins by calling this function, which has the
+effect of switching to Fundamental mode and erasing most of the effects
+of the previous major mode. To ensure that this does its job, the
+variables that major modes set should not be marked permanent.
+
+@code{kill-all-local-variables} returns @code{nil}.
+@end defun
+
+@c Emacs 19 feature
+@cindex permanent local variable
+A local variable is @dfn{permanent} if the variable name (a symbol) has a
+@code{permanent-local} property that is non-@code{nil}. Permanent
+locals are appropriate for data pertaining to where the file came from
+or how to save it, rather than with how to edit the contents.
+
+@node Default Value
+@subsection The Default Value of a Buffer-Local Variable
+@cindex default value
+
+ The global value of a variable with buffer-local bindings is also
+called the @dfn{default} value, because it is the value that is in
+effect except when specifically overridden.
+
+ The functions @code{default-value} and @code{setq-default} access and
+change a variable's default value regardless of whether the current
+buffer has a buffer-local binding. For example, you could use
+@code{setq-default} to change the default setting of
+@code{paragraph-start} for most buffers; and this would work even when
+you are in a C or Lisp mode buffer that has a buffer-local value for
+this variable.
+
+@c Emacs 19 feature
+ The special forms @code{defvar} and @code{defconst} also set the
+default value (if they set the variable at all), rather than any local
+value.
+
+@defun default-value symbol
+This function returns @var{symbol}'s default value. This is the value
+that is seen in buffers that do not have their own values for this
+variable. If @var{symbol} is not buffer-local, this is equivalent to
+@code{symbol-value} (@pxref{Accessing Variables}).
+@end defun
+
+@c Emacs 19 feature
+@defun default-boundp symbol
+The function @code{default-boundp} tells you whether @var{symbol}'s
+default value is nonvoid. If @code{(default-boundp 'foo)} returns
+@code{nil}, then @code{(default-value 'foo)} would get an error.
+
+@code{default-boundp} is to @code{default-value} as @code{boundp} is to
+@code{symbol-value}.
+@end defun
+
+@defspec setq-default symbol value
+This sets the default value of @var{symbol} to @var{value}. It does not
+evaluate @var{symbol}, but does evaluate @var{value}. The value of the
+@code{setq-default} form is @var{value}.
+
+If a @var{symbol} is not buffer-local for the current buffer, and is not
+marked automatically buffer-local, @code{setq-default} has the same
+effect as @code{setq}. If @var{symbol} is buffer-local for the current
+buffer, then this changes the value that other buffers will see (as long
+as they don't have a buffer-local value), but not the value that the
+current buffer sees.
+
+@example
+@group
+;; @r{In buffer @samp{foo}:}
+(make-local-variable 'local)
+ @result{} local
+@end group
+@group
+(setq local 'value-in-foo)
+ @result{} value-in-foo
+@end group
+@group
+(setq-default local 'new-default)
+ @result{} new-default
+@end group
+@group
+local
+ @result{} value-in-foo
+@end group
+@group
+(default-value 'local)
+ @result{} new-default
+@end group
+
+@group
+;; @r{In (the new) buffer @samp{bar}:}
+local
+ @result{} new-default
+@end group
+@group
+(default-value 'local)
+ @result{} new-default
+@end group
+@group
+(setq local 'another-default)
+ @result{} another-default
+@end group
+@group
+(default-value 'local)
+ @result{} another-default
+@end group
+
+@group
+;; @r{Back in buffer @samp{foo}:}
+local
+ @result{} value-in-foo
+(default-value 'local)
+ @result{} another-default
+@end group
+@end example
+@end defspec
+
+@defun set-default symbol value
+This function is like @code{setq-default}, except that @var{symbol} is
+evaluated.
+
+@example
+@group
+(set-default (car '(a b c)) 23)
+ @result{} 23
+@end group
+@group
+(default-value 'a)
+ @result{} 23
+@end group
+@end example
+@end defun
+
+@node Variable Aliases
+@section Variable Aliases
+@cindex variables, indirect
+@cindex indirect variables
+@cindex variable aliases
+@cindex aliases, for variables
+
+You can define a variable as an @dfn{alias} for another. Any time
+you reference the former variable, the current value of the latter
+is returned. Any time you change the value of the former variable,
+the value of the latter is actually changed. This is useful in
+cases where you want to rename a variable but still make old code
+work (@pxref{Obsoleteness}).
+
+@defun defvaralias variable alias
+This function defines @var{variable} as an alias for @var{alias}.
+Thenceforth, any operations performed on @var{variable} will actually be
+performed on @var{alias}. Both @var{variable} and @var{alias} should be
+symbols. If @var{alias} is @code{nil}, remove any aliases for
+@var{variable}. @var{alias} can itself be aliased, and the chain of
+variable aliases will be followed appropriately. If @var{variable}
+already has a value, this value will be shadowed until the alias is
+removed, at which point it will be restored. Currently @var{variable}
+cannot be a built-in variable, a variable that has a buffer-local value
+in any buffer, or the symbols @code{nil} or @code{t}.
+@end defun
+
+@defun variable-alias variable &optional follow-past-lisp-magic
+If @var{variable} is aliased to another variable, this function returns
+that variable. @var{variable} should be a symbol. If @var{variable} is
+not aliased, this function returns @code{nil}.
+@end defun
+
+@defun indirect-variable object &optional follow-past-lisp-magic
+This function returns the variable at the end of @var{object}'s
+variable-alias chain. If @var{object} is a symbol, follow all variable
+aliases and return the final (non-aliased) symbol. If @var{object} is
+not a symbol, just return it. Signal a
+@code{cyclic-variable-indirection} error if there is a loop in the
+variable chain of symbols.
+@end defun
+
+
projects / chise / xemacs-chise.git- / blobdiff