From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error. Date: Thu, 9 Apr 2009 23:12:01 -0400 Message-ID: References: <50950.128.165.123.18.1239229924.squirrel@webmail.lanl.gov> <33049.128.165.123.18.1239290817.squirrel@webmail.lanl.gov> <33849.128.165.123.18.1239316978.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1239333139 13624 80.91.229.12 (10 Apr 2009 03:12:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Apr 2009 03:12:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: herring@lanl.gov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 10 05:13:38 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 1Ls7BQ-0004os-84 for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2009 05:13:37 +0200 Original-Received: from localhost ([127.0.0.1]:55592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ls7A1-0006Hh-PN for ged-emacs-devel@m.gmane.org; Thu, 09 Apr 2009 23:12:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ls79x-0006HG-84 for emacs-devel@gnu.org; Thu, 09 Apr 2009 23:12:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ls79v-0006Gv-KE for emacs-devel@gnu.org; Thu, 09 Apr 2009 23:12:04 -0400 Original-Received: from [199.232.76.173] (port=56153 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ls79v-0006Gs-FT for emacs-devel@gnu.org; Thu, 09 Apr 2009 23:12:03 -0400 Original-Received: from yx-out-1718.google.com ([74.125.44.158]:54122) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ls79v-0001jp-4l for emacs-devel@gnu.org; Thu, 09 Apr 2009 23:12:03 -0400 Original-Received: by yx-out-1718.google.com with SMTP id 3so736376yxi.66 for ; Thu, 09 Apr 2009 20:12:01 -0700 (PDT) Original-Received: by 10.150.154.5 with SMTP id b5mr1265555ybe.247.1239333121689; Thu, 09 Apr 2009 20:12:01 -0700 (PDT) In-Reply-To: <33849.128.165.123.18.1239316978.squirrel@webmail.lanl.gov> X-Google-Sender-Auth: 88e07208155c12c6 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:110181 Archived-At: > Your quoting is still off, in general. Thank you. Your right. What knocks my socks off is it generally works without trouble... > 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. OK > Meanwhile, I can't imagine why you're quoting `t', or why you're calling Maybe I want to change that symbol's value to something else at some point? Maybe habit? Maybe a lack of understanding syntax? Again, its probably a testament to Emacs robustosity that the code made it this far without choking > `and' with only one argument, or why you're calling `progn' within the > body of a `let*'. Maybe i'm paranoid but ({.... do stuff with SOME ARGS ...})) includes nested lets/lets*, catch/throws, save-excursions, with-temp-buffer, etc. wrapping that in a progn wrapped in a let* seems to ensure that the return to the conditional (longlines-mode {nil/t}) gets executed as the last form. > > If you're in a temporary buffer that you created, longlines-mode isn't > active in it anyway. Obviously, but when shuffling the text between real<->temp buffers weird things seem to happen when I *don't* disable lLLM before leaving current-buffer > 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. Ok. but so long as it's _my_ buffer I'll (attempt) disabling it as I please warts and all :) Also, LLM doesn't *really* change text FWIU... only EOL representation no? > 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 ...))) I'll give it a gander but swapping a hook variable (one more poorly specified than the elisp variable I'm dancing around) doesn't strike me as quite the right thing. > > (bound-and-true-p 'longlines-mode) Thank You. This seems much cleaner and prob. exactly what is needed. > > Again, `fundamental-mode' is never a variable. Nor is any other major > mode. Then fundamental-mode shouldn't masquerade as one behind the major-mode elt in buffer-local-variable's alist pair. Doesn't this generally imply an assumption that one know which mode one is testing for? > > dir-locals are just data on disk that become buffer-local variables when a ??? Can't they reside outside of a dir-locals.el bound to a 'class'. > They are irrelevant here. Is this based on your assumption that dir-locals are _just_ data on disk? > 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. In which context? The contexts at hand are still (in my case) at the outer layers. ({.... do stuff with SOME ARGS ...})) does exist in various manifestations and is being put to active use on a _daily_ basis sloppy quoting or otherwise. I'd be happy to share the details but I doubt you'd benefit from pointing out all the deficiencies in my code (I'm sure the inverse isn't the case) :) Best, s_P