emacs-devel
[Top][All Lists]
Advanced

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

Re: [Fwd: [h-e-w] typo]


From: Stefan Monnier
Subject: Re: [Fwd: [h-e-w] typo]
Date: Fri, 11 Apr 2008 13:46:37 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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




reply via email to

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