From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Davis Herring" Newsgroups: gmane.emacs.devel Subject: Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error. Date: Thu, 9 Apr 2009 15:42:58 -0700 (PDT) Message-ID: <33849.128.165.123.18.1239316978.squirrel@webmail.lanl.gov> References: <50950.128.165.123.18.1239229924.squirrel@webmail.lanl.gov> <33049.128.165.123.18.1239290817.squirrel@webmail.lanl.gov> Reply-To: herring@lanl.gov NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1239317002 14765 80.91.229.12 (9 Apr 2009 22:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Apr 2009 22:43:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: "MON KEY" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 10 00:44:41 2009 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 1Ls2z9-0006pT-RT for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2009 00:44:40 +0200 Original-Received: from localhost ([127.0.0.1]:59351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ls2xl-0004kx-JW for ged-emacs-devel@m.gmane.org; Thu, 09 Apr 2009 18:43:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ls2xg-0004ki-OD for emacs-devel@gnu.org; Thu, 09 Apr 2009 18:43:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ls2xb-0004kT-2l for emacs-devel@gnu.org; Thu, 09 Apr 2009 18:43:07 -0400 Original-Received: from [199.232.76.173] (port=51228 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ls2xa-0004kQ-Ty for emacs-devel@gnu.org; Thu, 09 Apr 2009 18:43:02 -0400 Original-Received: from proofpoint1.lanl.gov ([204.121.3.25]:33019) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ls2xa-0007ad-CV for emacs-devel@gnu.org; Thu, 09 Apr 2009 18:43:02 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id n39MgwEv021042; Thu, 9 Apr 2009 16:42:59 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id E383910CD5CD; Thu, 9 Apr 2009 16:42:58 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (Postfix) with ESMTP id BC5D010CD5C9; Thu, 9 Apr 2009 16:42:58 -0600 (MDT) Original-Received: by webmail1.lanl.gov (Postfix, from userid 48) id BA74A1518033; Thu, 9 Apr 2009 16:42:58 -0600 (MDT) Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Thu, 9 Apr 2009 15:42:58 -0700 (PDT) User-Agent: SquirrelMail/1.4.8-5.3.lanl2 X-Priority: 3 (Normal) Importance: Normal In-Reply-To: X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-04-09_16:2009-04-09, 2009-04-09, 2009-04-09 signatures=0 X-detected-operating-system: by monty-python.gnu.org: GNU/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:110177 Archived-At: > (defun do-stuff-when-llm (some args) > (let* ((test-llm (and (buffer-local-value longlines-mode > (current-buffer)))) > (is-on (and test-llm)) > (llm-off)) > (progn > (when is-on (longlines-mode 0) (setq llm-off 't)) > (save-excursion > ({.... do stuff with SOME ARGS ...})) > (when llm-off > (longlines-mode 1) (setq llm-off 'nil))))) Your quoting is still off, in general. You should be using (buffer-local-value 'longlines-mode ...), and there's no reason that I can think of for you to use (buffer-local-value 'anything (current-buffer)), because buffer-local values for the current buffer are already in force without having to call `buffer-local-value' at all. Meanwhile, I can't imagine why you're quoting `t', or why you're calling `and' with only one argument, or why you're calling `progn' within the body of a `let*'. > In these cases longlines-mode is (typically) already buffer-local per > my-major modes defaults (a derived mode of my own creation). The > excursion code usually operate in a vanilla with-temp-buffer where > longlines-mode _isn't_ wanted so i turn off the longlines-mode before > grabbing the region and leaving. After processing in temp the region > comes back in and longlines-mode is activated again.... If you're in a temporary buffer that you created, longlines-mode isn't active in it anyway. If you're in a user's buffer, you probably don't want to do something so heavyweight as disabling and reenabling longlines-mode, because it involves changing the text in the buffer. If you merely want to prevent longlines-mode (and anything else) from responding to changes you're making (in a buffer where it's active), you can just bind `inhibit-modification-hooks': (defun frob-without-mod-hooks (...) (let ((inhibit-modification-hooks t)) (frob ...))) > that it hasn't loaded in longlines-mode code (it's autoload stuff) so, > in _these_ cases the code above breaks. It breaks in those cases because `longlines-mode' is just a symbol (and not a variable) until its package is loaded. This has nothing to do with `buffer-local-value', except that quoting the variable won't be enough because `buffer-local-value' will still find it to be void when it looks. If you need to detect (and not just suppress) longlines-mode without having to load it, you can do (bound-and-true-p 'longlines-mode) > but in fact it happens with Fundamental mode as well. Once Emacs > becomes aware of longlines-mode the minor-mode buffer-local 'bug' > disappears. However, it remains for fundamental mode which BTW is > basically special [...] Again, `fundamental-mode' is never a variable. Nor is any other major mode. If you want to test a major mode, you use the variable `major-mode'. > After looking over subr.el last night I feel that the data structures > and wrapping functions packing all the buffer-local stuff away is > kludgy in corner cases and frustratingly inconsistent with regards to > how variables are created/accessed/unbound - one only wonders what is > going to happen with the newer dir-locals interaction alongside > buffer-locals. dir-locals are just data on disk that become buffer-local variables when a file under their directory is visited. They are irrelevant here. There are indeed some strange corner cases with buffer-locals, like the interaction of `let' and `set-buffer' with buffer-local variables. But you haven't found any in this context. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.