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 15:16:47 -0500 Message-ID: References: <4759ED09.7060601@gmail.com> <475ADCA4.1020506@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1197145023 6628 80.91.229.12 (8 Dec 2007 20:17:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Dec 2007 20:17:03 +0000 (UTC) Cc: Emacs Devel To: "Lennart Borgman \(gmail\)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 08 21:17:13 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 1J166q-00032Z-9B for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2007 21:17:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J166Y-0000Yb-UR for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2007 15:16:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J166U-0000Wy-Uh for emacs-devel@gnu.org; Sat, 08 Dec 2007 15:16:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J166T-0000Uo-65 for emacs-devel@gnu.org; Sat, 08 Dec 2007 15:16:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J166S-0000Uf-Nj for emacs-devel@gnu.org; Sat, 08 Dec 2007 15:16:48 -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 1J166S-0000vz-Bt for emacs-devel@gnu.org; Sat, 08 Dec 2007 15:16:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF+KWkfO+J2ydGdsb2JhbACPYQEw X-IronPort-AV: E=Sophos;i="4.23,271,1194238800"; d="scan'208";a="11097503" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 08 Dec 2007 15:16:48 -0500 Original-Received: from pastel.home ([206.248.157.178]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id NGY67147; Sat, 08 Dec 2007 15:16:47 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 28CEC7F79; Sat, 8 Dec 2007 15:16:46 -0500 (EST) In-Reply-To: <475ADCA4.1020506@gmail.com> (Lennart Borgman's message of "Sat, 08 Dec 2007 19:04:20 +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:84893 Archived-At: >>> It surprises me that beginning/end-of-defun-function are not always >>> buffer local. >> >> Why force them to be buffer-local? When you need to set them in >> a buffer, just do >> >> (set (make-local-variable 'end-of-defun-function) 'foo) >> >> If you think that's too long, then you may want to request a new >> `setq-local' macro. > setq-local would be a good idea. > But I do not understand how you think in this case. Are not the > variables above always meant to be buffer local? I don't see why they should always be buffer-local. It is quite meaningful to set this variable globally so as to get a new improved default behavior. > 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. Stefan