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: Proposal: `buffer-offer-save' be made a permanent-local Date: Thu, 17 Jun 2010 17:36:57 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1276810630 26883 80.91.229.12 (17 Jun 2010 21:37:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 21:37:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: kevin.d.rodgers@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 17 23:37:09 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OPMlo-0008IC-Qr for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 23:37:09 +0200 Original-Received: from localhost ([127.0.0.1]:56994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPMln-0006Bt-UC for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 17:37:08 -0400 Original-Received: from [140.186.70.92] (port=50525 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPMlf-00068A-7Z for emacs-devel@gnu.org; Thu, 17 Jun 2010 17:37:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPMle-0002y9-8d for emacs-devel@gnu.org; Thu, 17 Jun 2010 17:36:59 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:40215) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPMle-0002xz-4m for emacs-devel@gnu.org; Thu, 17 Jun 2010 17:36:58 -0400 Original-Received: by gwj23 with SMTP id 23so257672gwj.0 for ; Thu, 17 Jun 2010 14:36:57 -0700 (PDT) Original-Received: by 10.150.161.22 with SMTP id j22mr138370ybe.54.1276810617124; Thu, 17 Jun 2010 14:36:57 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Thu, 17 Jun 2010 14:36:57 -0700 (PDT) X-Google-Sender-Auth: YRS33RlfmaRD5lkMPUdnHbRFDvg X-detected-operating-system: by eggs.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:126105 Archived-At: Kevin Rodgers wrote: > Isn't it as easy as: > > (put 'nonpermanent-local-variable 'permanent-local t) Yep, and therein lies the rub. My major-mode did this instead: (put 'deadweight-unless-you-look-for-me 'permanent-local t) How does _your_ major-mode know to test for this permanent local? And vice versa, how does _my_ major-mode know to test for `nonpermanent-local-variable'? Right now we rely on the scorched earth tactics of `kill-all-local-variables' to resolve these sorts of ambiguities. IOW we napalm the room to erase whatever farts the previous fella left behind. And, in general this approach has been a fairly effective form of air freshener but doesn't cover up certain lingering odors: ,---- | As a special exception, local variables whose names have a non-nil | `permanent-local' property are not eliminated by this function. | `---- (describe-function 'kill-all-local-variables) If you find the existing approach above ugly then you may then agree with the proposed solution to: a) elevate some symbol e.g. `buffer-offer-save' to a higher status b) teach your major-mode to check for this symbol (where applicable) c) hope everyone elses major-modes do this as well d) wait for Emacs to begin verbosely prompting you to save every last useless buffer you visited _before_ she will allow her process to terminate. e) Seek out the offending elisp code that did: (set (make-local-variable 'buffer-offer-save) t) i) Check in a coupla places 'cause the major-mode/code which first set the var may be two or three times removed. f) Having located the offending code fire off a disgruntled email to the responsible party asking why they thought it reasonable to reach into your Emacsen and toggle that variable in _your_ buffers without first asking if it was kosher to do so... g) Become increasingly baffled when said coder explains that while the property _was_ set by his code _you_ are wrong to be miffed b/c he assumed: "this is what most people expect. You are the corner case. Sorry 'bout that" Good luck trying to explain to someone how it is that the real exceptional special circumstance isn't your expectations but the permanent local variable that keeps getting flipped behind your back when you aren't looking. -- /s_P\