From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Fwd: [h-e-w] typo] Date: Fri, 11 Apr 2008 13:46:37 -0400 Message-ID: References: <47F27EBE.4020107@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207936078 4394 80.91.229.12 (11 Apr 2008 17:47:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2008 17:47:58 +0000 (UTC) Cc: Emacs Devel To: "Lennart Borgman \(gmail\)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 11 19:48:31 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 1JkNMT-0003lm-Ub for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2008 19:48:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JkNLq-0006K9-4s for ged-emacs-devel@m.gmane.org; Fri, 11 Apr 2008 13:47:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JkNKj-0005d3-5F for emacs-devel@gnu.org; Fri, 11 Apr 2008 13:46:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JkNKh-0005bT-M5 for emacs-devel@gnu.org; Fri, 11 Apr 2008 13:46:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JkNKh-0005bN-80 for emacs-devel@gnu.org; Fri, 11 Apr 2008 13:46:39 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JkNKg-0004pj-Sg for emacs-devel@gnu.org; Fri, 11 Apr 2008 13:46:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFANxA/0fO+KV8/2dsb2JhbACBXalw X-IronPort-AV: E=Sophos;i="4.25,642,1199682000"; d="scan'208";a="18361985" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 11 Apr 2008 13:46:38 -0400 Original-Received: from pastel.home ([206.248.165.124]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id RVF21838; Fri, 11 Apr 2008 13:46:38 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D8A748487; Fri, 11 Apr 2008 13:46:37 -0400 (EDT) In-Reply-To: <47F27EBE.4020107@gmail.com> (Lennart Borgman's message of "Tue, 01 Apr 2008 20:28:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:94980 Archived-At: > -- 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