[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[h-e-w] typo

From: David R
Subject: [h-e-w] typo
Date: Sun, 30 Mar 2008 23:39:02 +0100
User-agent: Thunderbird (Windows/20070809)

11.10.2 Creating and Deleting Buffer-Local Bindings

-- Command: make-variable-buffer-local variable
This function marks 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.


File: elisp, Node: Creating Buffer-Local, Next: Default Value, Prev: Intro to Buffer-Local, Up: Buffer-Local Variables

11.10.2 Creating and Deleting Buffer-Local Bindings

-- Command: make-local-variable variable
    This function creates a buffer-local binding in the current buffer
    for VARIABLE (a symbol).  Other buffers are not affected.  The
    value returned is VARIABLE.

    The buffer-local value of VARIABLE starts out as the same value
    VARIABLE previously had.  If VARIABLE was void, it remains void.

         ;; In buffer `b1':
         (setq foo 5)                ; Affects all buffers.
              => 5
         (make-local-variable 'foo)  ; Now it is local in `b1'.
              => foo
         foo                         ; That did not change
              => 5                   ;   the value.
         (setq foo 6)                ; Change the value
              => 6                   ;   in `b1'.
              => 6

         ;; In buffer `b2', the value hasn't changed.
           (set-buffer "b2")
              => 5

    Making a variable buffer-local within a `let'-binding for that
    variable does not work reliably, unless the buffer in which you do
    this is not current either on entry to or exit from the `let'.
Why would this work?

    This is because `let' does not distinguish between different kinds
    of bindings; it knows only which variable the binding was made for.

so using a buffer-local in a non-current buffer would alter the value in the current buffer It stand to reason that a buffer-local in the current buffer would tally the same also?
I don't unferstand this significance of the non-current necessity.

    If the variable is terminal-local, this function signals an error.
    Such variables cannot have buffer-local bindings as well.  *Note
    Multiple Displays::.

    *Warning:* do not use `make-local-variable' for a hook variable.
    The hook variables are automatically made buffer-local as needed
    if you use the LOCAL argument to `add-hook' or `remove-hook'.

-- Command: make-variable-buffer-local variable
    This function marks 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.

    A peculiar wrinkle of this feature is that binding the variable
    (with `let' or other binding constructs) does not create a
    buffer-local binding for it.  Only setting the variable (with
    `set' or `setq'), while the variable does not have a `let'-style
    binding that was made in the current buffer, does so.

    If VARIABLE does not have a default value, then calling this
    command will give it a default value of `nil'.  If VARIABLE
    already has a default value, that value remains unchanged.
this value as the default value, or the present value of the variable?
What happens to the present value of the variable : does it become the
value as the value of the default?  Does it remain unchanged?

    Subsequently calling `makunbound' on VARIABLE will result in a
    void buffer-local value and leave the default value unaffected.

    The value returned is VARIABLE.

    *Warning:* Don't assume that you should use
    `make-variable-buffer-local' for user-option variables, simply
    because users _might_ want to customize them differently in
    different buffers.  Users can make any variable local, when they
    wish to.  It is better to leave the choice to them.

    The time to use `make-variable-buffer-local' is when it is crucial
    that no two buffers ever share the same binding.  For example,
    when a variable is used for internal purposes in a Lisp program
    which depends on having separate values in separate buffers, then
    using `make-variable-buffer-local' can be the best solution.

-- Function: local-variable-p variable &optional buffer
    This returns `t' if VARIABLE is buffer-local in buffer BUFFER
    (which defaults to the current buffer); otherwise, `nil'.

Can this be called at a different buffer than where the query is being made by?
I guess so, but guessing can be eliminated.

-- Function: local-variable-if-set-p variable &optional buffer
    This returns `t' if VARIABLE will become buffer-local in buffer
    BUFFER (which defaults to the current buffer) if it is set there.

-- Function: buffer-local-value variable buffer
    This function returns the buffer-local binding of VARIABLE (a
    symbol) in buffer BUFFER.  If VARIABLE does not have a
    buffer-local binding in buffer BUFFER, it returns the default
    value (*note Default Value::) of VARIABLE instead.

-- Function: buffer-local-variables &optional buffer
    This function returns a list describing the buffer-local variables
    in buffer BUFFER.  (If BUFFER is omitted, the current buffer is
    used.)  It returns an association list (*note Association Lists::)
    in which each element contains one buffer-local variable and its
    value.  However, when a variable's buffer-local binding in BUFFER
    is void, then the variable appears directly in the resulting list.

         (make-local-variable 'foobar)
         (makunbound 'foobar)
         (make-local-variable 'bind-me)
         (setq bind-me 69)
         (setq lcl (buffer-local-variables))
             ;; First, built-in variables local in all buffers:
         => ((mark-active . nil)
             (buffer-undo-list . nil)
             (mode-name . "Fundamental")
             ;; Next, non-built-in buffer-local variables.
             ;; This one is buffer-local and void:
             ;; This one is buffer-local and nonvoid:
             (bind-me . 69))

    Note that storing new values into the CDRs of cons cells in this
    list does _not_ change the buffer-local values of the variables.

This seem peculiar.
Why is this?

-- Command: kill-local-variable variable
    This function deletes the buffer-local binding (if any) for
    VARIABLE (a symbol) in the current buffer.  As a result, the
    default binding of VARIABLE becomes visible in this buffer.  This
    typically results in a change in the value of VARIABLE, since the
    default value is usually different from the buffer-local value just

    If you kill the buffer-local binding of a variable that
    automatically becomes buffer-local when set, this makes the
    default value visible in the current buffer.  However, if you set
    the variable again, that will once again create a buffer-local
    binding for it.

    `kill-local-variable' returns 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.

-- Function: 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 `nil', the syntax table to
    the value of `(standard-syntax-table)', the case table to
    `(standard-case-table)', and the abbrev table to the value of

    The very first thing this function does is run the normal hook
    `change-major-mode-hook' (see below).

    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.

    `kill-all-local-variables' returns `nil'.

-- Variable: change-major-mode-hook
    The function `kill-all-local-variables' runs this normal hook
    before it does anything else.  This gives major modes a way to
    arrange for something special to be done if the user switches to a
    different major mode.  It is also useful for buffer-specific minor
    modes that should be forgotten if the user changes the major mode.

    For best results, make this variable buffer-local, so that it will
    disappear after doing its job and will not interfere with the
    subsequent major mode.  *Note Hooks::.

  A buffer-local variable is "permanent" if the variable name (a
symbol) has a `permanent-local' property that is non-`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.

File: elisp, Node: Calling Functions, Next: Mapping Functions, Prev: Defining Functions, Up: Functions

12.5 Calling Functions

Defining functions is only half the battle.  Functions don't do
anything until you "call" them, i.e., tell them to run.  Calling a
function is also known as "invocation".

  The most common way of invoking a function is by evaluating a list.
For example, evaluating the list `(concat "a" "b")' calls the function
`concat' with arguments `"a"' and `"b"'.  *Note Evaluation::, for a
description of evaluation.

  When you write a list as an expression in your program, you specify
which function to call, and how many arguments to give it, in the text
of the program.  Usually that's just what you want.  Occasionally you
need to compute at run time which function to call.  To do that, use
the function `funcall'.  When you also need to determine at run time
how many arguments to pass, use `apply'.

-- Function: funcall function &rest arguments
    `funcall' calls FUNCTION with ARGUMENTS, and returns whatever
    FUNCTION returns.

    Since `funcall' is a function, all of its arguments, including
    FUNCTION, are evaluated before `funcall' is called.  This means
    that you can use any expression to obtain the function to be
    called.  It also means that `funcall' does not see the expressions
    you write for the ARGUMENTS, only their values.  These values are
    _not_ evaluated a second time in the act of calling FUNCTION; the
    operation of `funcall' is like the normal procedure for calling a
    function, once its arguments have already been evaluated.

    The argument FUNCTION must be either a Lisp function or a
    primitive function.  Special forms and macros are not allowed,
    because they make sense only when given the "unevaluated" argument
    expressions.  `funcall' cannot provide these because, as we saw
    above, it never knows them in the first place.

         (setq f 'list)
              => list
         (funcall f 'x 'y 'z)
              => (x y z)
         (funcall f 'x 'y '(z))
              => (x y (z))
         (funcall 'and t nil)
         error--> Invalid function: #<subr and>

    Compare these examples with the examples of `apply'.

-- Function: apply function &rest arguments
    `apply' calls FUNCTION with ARGUMENTS, just like `funcall' but
    with one difference: the last of ARGUMENTS is a list of objects,
    which are passed to FUNCTION as separate arguments, rather than a
    single list.  We say that `apply' "spreads" this list so that each
    individual element becomes an argument.
Are these arguments evaluated?

    `apply' returns the result of calling FUNCTION.  As with
    `funcall', FUNCTION must either be a Lisp function or a primitive
    function; special forms and macros do not make sense in `apply'.

         (setq f 'list)
              => list
         (apply f 'x 'y 'z)
         error--> Wrong type argument: listp, z
         (apply '+ 1 2 '(3 4))
              => 10
         (apply '+ '(1 2 3 4))
              => 10

         (apply 'append '((a b c) nil (x y z) nil))
              => (a b c x y z)

    For an interesting example of using `apply', see *Note Definition
    of mapcar::.

  It is common for Lisp functions to accept functions as arguments or
find them in data structures (especially in hook variables and property
lists) and call them using `funcall' or `apply'.  Functions that accept
function arguments are often called "functionals".

  Sometimes, when you call a functional, it is useful to supply a no-op
function as the argument.  Here are two different kinds of no-op

What does no-op mean?

-- Function: identity arg
    This function returns ARG and has no side effects.

-- Function: ignore &rest args
    This function ignores any arguments and returns `nil'.

*** E-Mail body has been placed on clipboard, please paste them here! ***

reply via email to

[Prev in Thread] Current Thread [Next in Thread]