all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [Fwd: [h-e-w] typo]
@ 2008-04-01 18:28 Lennart Borgman (gmail)
  2008-04-11 17:46 ` Stefan Monnier
  0 siblings, 1 reply; 2+ messages in thread
From: Lennart Borgman (gmail) @ 2008-04-01 18:28 UTC (permalink / raw)
  To: Emacs Devel



-------- Original Message --------
Subject: [h-e-w] typo
Date: Sun, 30 Mar 2008 23:39:02 +0100
From: David R <angel_ov_north@tiscali.co.uk>
To: help-emacs-windows@gnu.org


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.

makes?

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'.
          foo
               => 6

          ;; In buffer `b2', the value hasn't changed.
          (save-excursion
            (set-buffer "b2")
            foo)
               => 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:
              foobar
              ;; 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
     eliminated.

     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
     `fundamental-mode-abbrev-table'.

     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
function:

^^^
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! ***







^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Fwd: [h-e-w] typo]
  2008-04-01 18:28 [Fwd: [h-e-w] typo] Lennart Borgman (gmail)
@ 2008-04-11 17:46 ` Stefan Monnier
  0 siblings, 0 replies; 2+ messages in thread
From: Stefan Monnier @ 2008-04-11 17:46 UTC (permalink / raw)
  To: Lennart Borgman (gmail); +Cc: Emacs Devel

> -- 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.

> makes?

The function doesn't make the variable local to any buffer.  It just
marks it so that `set' will make the variable local to the buffer where
`set' is run.  So "marks" seems just as correct as "makes".

>     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?

Not sure I understand the question (esp. since the indentation of your
^^^ was somehow lost along the way).

>     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

I do not know what you mean by that.  So I cannot answer the
subsequent question.

> -- 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's the difference?  The "default value" of a variable is its
non-buffer-local value:

   (default-value symbol)
   
   Return symbol's default value.
   This is the value that is seen in buffers that do not have their own
   values for this variable.  The default value is meaningful for
   variables with local bindings in certain buffers.

> -- 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.

I must be missing something: "where the query is made" is
`current-buffer', so if you couldn't "call it at a different buffer"
what would be the use of the BUFFER argument?

>     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?

Think about it: buffer-local-values returns a copy of the relevant data,
since the internal data may not even be an alist at all (and indeed,
some of that data happens to be represented as an alist, but some of it
is represented completely differently and buffer-local-values
combines them.

> -- 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?

As long as you don't use macros, everything is evaluated once, no more
no less.  Calling a function always evaluates all the arguments before
entering the function's body.  `apply' is a function.  So yes, the
arguments are evaluated.  But `apply' does not evaluate them.

>   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
> function:

> ^^^
> What does no-op mean?

"No operation".  Also known as "nop" (a mnemonic used in assembler).


        Stefan




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-04-11 17:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-01 18:28 [Fwd: [h-e-w] typo] Lennart Borgman (gmail)
2008-04-11 17:46 ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.