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: Why is not end-of-defun-function buffer local? Date: Sat, 08 Dec 2007 21:45:55 -0500 Message-ID: References: <4759ED09.7060601@gmail.com> <475ADCA4.1020506@gmail.com> <475B48A7.2030509@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1197168372 28315 80.91.229.12 (9 Dec 2007 02:46:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Dec 2007 02:46:12 +0000 (UTC) Cc: Emacs Devel To: "Lennart Borgman \(gmail\)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 09 03:46:20 2007 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 1J1CBO-0008Uu-Pu for ged-emacs-devel@m.gmane.org; Sun, 09 Dec 2007 03:46:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1CB7-0007F4-JT for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2007 21:46:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J1CB4-0007Df-An for emacs-devel@gnu.org; Sat, 08 Dec 2007 21:45:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J1CB3-0007Ct-Oc for emacs-devel@gnu.org; Sat, 08 Dec 2007 21:45:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1CB3-0007Cd-Hy for emacs-devel@gnu.org; Sat, 08 Dec 2007 21:45:57 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J1CB3-0007mZ-6l for emacs-devel@gnu.org; Sat, 08 Dec 2007 21:45:57 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKflWkdMCpwi/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.23,272,1194238800"; d="scan'208";a="11104155" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 08 Dec 2007 21:45:55 -0500 Original-Received: from pastel.home ([76.10.156.34]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id OOC46855; Sat, 08 Dec 2007 21:45:55 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 079497F79; Sat, 8 Dec 2007 21:45:54 -0500 (EST) In-Reply-To: <475B48A7.2030509@gmail.com> (Lennart Borgman's message of "Sun, 09 Dec 2007 02:45:11 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (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:84909 Archived-At: >>> Looking at some code that is a bit older it looks like some of it uses >>> make-local-variable where it is not needed since the variables in question >>> are always buffer local. From that I draw the conclusion that the code in >>> Emacs uses make-variable-buffer-local more often now. Is not that the case? >> >> make-variable-buffer-local has the following downsides: >> 1 - it cannot be reverted. >> 2 - it may be done too late. >> 3 - when you see `setq' it's not obvious that the setting is buffer-local >> unless you remember seeing the call to make-variable-buffer-local. >> The second problem may also explain what you're seeing: some code may >> set a variable before the make-variable-buffer-local gets run. >> It's actually "common" to introduce bugs this way, because people see >> "this is automatically buffer-local" in the C-h v info, so they just use >> `setq' without realizing that the setq may occur before the package >> gets loaded. >> make-variable-buffer-local is not evil, but make-local-variable is much >> tamer and more explicit, and it works just as well in most cases. > Thanks, that was a good explanation. Why not add this to the doc string of > make-variable-buffer-local? Oh, and since I've been looking at the low-level code that handles variable lookup and things like that, there's another reason: make-variable-buffer-local has a very subtle semantics which requires pretty ugly and debatable C code. More specifically, the problem is to decide *when* to make a variable buffer-local. I.e. Setting the variable via `setq' should make it buffer-local, but setting it with `let' shouldn't. But (let ((var 1)) (setq var 2)) should not make `var' buffer-local either, because the `setq' is "protected" within a let. OTOH (let ((var 1)) (with-current-buffer (setq var 2))) should make `var' buffer-local in unless the code is itself run within a `let' which was itself done in . Yuck! So every `setq' on a variable that has been make-variable-buffer-local may require walking up the current list of `let' bindings to decide whether to make the variable buffer-local. Yup, that's right: the (setq var 2) will take time proportional to the stack depth :-( And in order to be able to walk up the stack and decide which let binding might be relevant, the runtime representation of some let-bindings requires an extra cons-cell, which is not used for anything else. Stefan