From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: [Fwd: [h-e-w] typo] Date: Tue, 01 Apr 2008 20:28:14 +0200 Message-ID: <47F27EBE.4020107@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207097853 7871 80.91.229.12 (2 Apr 2008 00:57:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Apr 2008 00:57:33 +0000 (UTC) To: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 02 02:58:03 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JgrIa-0002jA-BB for ged-emacs-devel@m.gmane.org; Wed, 02 Apr 2008 02:57:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JgrHy-0003eX-8C for ged-emacs-devel@m.gmane.org; Tue, 01 Apr 2008 20:57:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JgrEf-0001OM-J1 for emacs-devel@gnu.org; Tue, 01 Apr 2008 20:53:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JgrEf-0001O3-97 for emacs-devel@gnu.org; Tue, 01 Apr 2008 20:53:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JgrEe-0001Nw-Ma for emacs-devel@gnu.org; Tue, 01 Apr 2008 20:53:52 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JgrEd-0003ex-VB for emacs-devel@gnu.org; Tue, 01 Apr 2008 20:53:52 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JglGZ-00047n-Ao for emacs-devel@gnu.org; Tue, 01 Apr 2008 14:31:27 -0400 Original-Received: from c83-254-150-27.bredband.comhem.se ([83.254.150.27]:60537 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JglDS-0007QD-8P for emacs-devel@gnu.org; Tue, 01 Apr 2008 20:28:15 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 X-Antivirus: avast! (VPS 080331-0, 2008-03-31), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.150.27 X-Scan-Result: No virus found in message 1JglDS-0007QD-8P. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1JglDS-0007QD-8P 2c7e7a4763156a7279c1c517118997bf X-detected-kernel: by mx20.gnu.org: Linux 2.6? (barebone, rare!) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94149 Archived-At: -------- Original Message -------- Subject: [h-e-w] typo Date: Sun, 30 Mar 2008 23:39:02 +0100 From: David R 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: # 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! ***