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: Proposal: `buffer-offer-save' be made a permanent-local Date: Sun, 13 Jun 2010 21:00:42 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1276477259 17334 80.91.229.12 (14 Jun 2010 01:00:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 01:00:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 14 03:00:58 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 1ONy2q-0001pD-VM for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 03:00:57 +0200 Original-Received: from localhost ([127.0.0.1]:35589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONy2q-00072I-Gb for ged-emacs-devel@m.gmane.org; Sun, 13 Jun 2010 21:00:56 -0400 Original-Received: from [140.186.70.92] (port=34431 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONy2g-00070U-TX for emacs-devel@gnu.org; Sun, 13 Jun 2010 21:00:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONy2e-0005NW-Id for emacs-devel@gnu.org; Sun, 13 Jun 2010 21:00:46 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:40200 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONy2e-0005NQ-Gg for emacs-devel@gnu.org; Sun, 13 Jun 2010 21:00:44 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKMcFUxMCoQR/2dsb2JhbACed3K9c4UaBI0C X-IronPort-AV: E=Sophos;i="4.53,412,1272859200"; d="scan'208";a="67965850" Original-Received: from 76-10-132-17.dsl.teksavvy.com (HELO pastel.home) ([76.10.132.17]) by ironport2-out.pppoe.ca with ESMTP; 13 Jun 2010 21:00:42 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A3A8D80BC; Sun, 13 Jun 2010 21:00:42 -0400 (EDT) In-Reply-To: (MON KEY's message of "Sun, 13 Jun 2010 20:17:38 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.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:125886 Archived-At: > IIUC Stefan's rationale for consideration of making > `buffer-offer-save' permanent-local is that it would ease the burden > placed on major-modes (and their authors) to set/check for the > presence of `buffer-offer-save' by making the value a permanent No. If buffer-offer-save is bound to a major-mode, then it should not be permanent-local (i.e. if that variable is permanent-local, then the major-mode will need to use change-major-mode-hook to kill that var explicitly). The uses where buffer-offer-save would need to be permanent-local are uses where this state is not bound to a major-mode. AFAICT, all current uses of buffer-offer-save in Emacs are in places where the major-mode is not expected to change and where, in case it does change, it doesn't matter much what happens anyway. > Consideration of following exchange which transpired between RMS and > Stefan on emacs-devel circa 2003-06-01 as thread: > "Re: kill-buffer-hook permanent-local" > has caused me some doubt as to whether the current proposed change is > TRT and is in keeping with the rationale for other similar such > changes in the past: The exchange explains how making kill-buffer-hook permanent-local is not too terrible, because specific major-modes can override the permanence via change-major-mode-hook. That same argument applies to any variable, including buffer-offer-save. > IMHO Emacs is better served moving _away_ from permanent-locals and > other sorts of heavy-handed globals with an implicit reliance on > dynamic-scoping and instead seek to find/incorporate first-class > lexical-scoping solutions which can better accommodate both the user > and package developers. While the permanent-local property is global, it doesn't mean that it's bad in the same sense as a global variable. More specifically, the fact that a variable is not permanent-local, is *also* a global property. And while a permanent-local variable can easily be made non-permanent via change-major-mode-hook, it is a lot more difficult to reliably make a non-permanent-local variable permanent. So your general argument might end up arguing in favor of making all variables permanent-local. Stefan