From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local Date: Fri, 18 Jun 2010 00:25:23 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1276813558 4132 80.91.229.12 (17 Jun 2010 22:25:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Jun 2010 22:25:58 +0000 (UTC) Cc: kevin.d.rodgers@gmail.com, emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 18 00:25:57 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 1OPNWy-0001EK-HU for ged-emacs-devel@m.gmane.org; Fri, 18 Jun 2010 00:25:52 +0200 Original-Received: from localhost ([127.0.0.1]:52699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPNWy-00028i-0Q for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 18:25:52 -0400 Original-Received: from [140.186.70.92] (port=56100 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPNWr-00026z-M7 for emacs-devel@gnu.org; Thu, 17 Jun 2010 18:25:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPNWq-00012B-3U for emacs-devel@gnu.org; Thu, 17 Jun 2010 18:25:45 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:41281) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPNWq-00011y-19 for emacs-devel@gnu.org; Thu, 17 Jun 2010 18:25:44 -0400 Original-Received: by yxf34 with SMTP id 34so38648yxf.0 for ; Thu, 17 Jun 2010 15:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rq5oCsMfVwcGxUzwVYcBdhgKjEugX2LsvQEox/IK8vo=; b=tZl8Iz0KltosvMZ5rpVC+Ns457ZY2sNMOy8UAIbpJ5vYbqSOaGp3csAOiEGi38+HHr VLn/VAT2MqWiPQOrJyC+WLPF/8Tbvl+f2s38g+cjrLYCNC4nDAVJVdL5WqcsK0VGCdwW 40Z6LihKdS/ttbJ5lrpo4/quKGBoBqVsfW70Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=r0UbUBm3rnIwmwIz8p1Z9s0pBC6QkgzBbI9MBFvjgN2IyxIm+LRn+3Hz07Ips+V/yb IkrGtS2ziwLzOWa1p9VGIJwsi9w8le5nhZR/xBK2VuoXNd45chnm+MgFKq2lEKvbV1WA gtBWbnC+hQDhOHeItSY9Rfl+kvD5m4LBLBRCA= Original-Received: by 10.101.195.2 with SMTP id x2mr138758anp.211.1276813543288; Thu, 17 Jun 2010 15:25:43 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Thu, 17 Jun 2010 15:25:23 -0700 (PDT) In-Reply-To: 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:126107 Archived-At: On Thu, Jun 17, 2010 at 11:36 PM, MON KEY wrote: > 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) Is not this just a misuse of a feature? You can misuse any feature. Your major mode is simply not expected to to this kind of things. It is not expected to do a lot of other things either. And this has nothing to do with the change I proposed. Instead, as I said before (a bit less explicit) it rather has to do with complexity. > 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. =C2=A0And, 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: > > =C2=A0a) elevate some symbol e.g. `buffer-offer-save' to a higher status > > =C2=A0b) teach your major-mode to check for this symbol (where applicable= ) > > =C2=A0c) hope everyone elses major-modes do this as well > > =C2=A0d) wait for Emacs to begin verbosely prompting you to save every la= st > =C2=A0 =C2=A0useless buffer you visited _before_ she will allow her proce= ss to > =C2=A0 =C2=A0terminate. > > =C2=A0e) Seek out the offending elisp code that did: > > =C2=A0 =C2=A0(set (make-local-variable 'buffer-offer-save) t) > > =C2=A0 =C2=A0i) Check in a coupla places 'cause the major-mode/code which= first > =C2=A0 =C2=A0 =C2=A0 =C2=A0set the var may be two or three times removed. > > =C2=A0f) Having located the offending code fire off a disgruntled email t= o > =C2=A0 =C2=A0the responsible party asking why they thought it reasonable = to > =C2=A0 =C2=A0reach into your Emacsen and toggle that variable in _your_ b= uffers > =C2=A0 =C2=A0without first asking if it was kosher to do so... > > =C2=A0g) Become increasingly baffled when said coder explains that while = the > =C2=A0 =C2=A0property _was_ set by his code _you_ are wrong to be miffed = b/c he > =C2=A0 =C2=A0assumed: > > =C2=A0 =C2=A0"this is what most people expect. > =C2=A0 =C2=A0 You are the corner case. > =C2=A0 =C2=A0 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\ > >