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: Mon, 14 Jun 2010 09:38:07 -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 1276522700 21292 80.91.229.12 (14 Jun 2010 13:38:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 13:38:20 +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 15:38:19 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 1OO9rm-0002GN-OC for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 15:38:19 +0200 Original-Received: from localhost ([127.0.0.1]:42949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO9rm-0004NJ-0U for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 09:38:18 -0400 Original-Received: from [140.186.70.92] (port=52481 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO9re-0004MO-Hl for emacs-devel@gnu.org; Mon, 14 Jun 2010 09:38:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OO9rd-0005OP-AD for emacs-devel@gnu.org; Mon, 14 Jun 2010 09:38:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:12379 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO9rd-0005OA-8J for emacs-devel@gnu.org; Mon, 14 Jun 2010 09:38:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvNFUxMCoQR/2dsb2JhbACefXK/IIUaBI0C X-IronPort-AV: E=Sophos;i="4.53,414,1272859200"; d="scan'208";a="67988785" Original-Received: from 76-10-132-17.dsl.teksavvy.com (HELO alfajor.home) ([76.10.132.17]) by ironport2-out.pppoe.ca with ESMTP; 14 Jun 2010 09:38:07 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 61FE4AE251; Mon, 14 Jun 2010 09:38:07 -0400 (EDT) In-Reply-To: (MON KEY's message of "Mon, 14 Jun 2010 04:48:12 -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:125905 Archived-At: >> 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). > So, the burden is shifted from major-mode authors and users to check/test for > the property where the check has not otherwise been explicitly required of > either in the past? I have no idea what "check/test" you're referring to. >> 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. > So, is it fair to assume that for these major-mode's which are not > expected to change there is no particular benefit/gain of having > buffer-offer-save permanent-local? Yes. >> 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. > Maybe, but they don't necessarily apply in the same way though b/c: > - buffer-offer-save is a boolean**; Why would that matter? > - buffer-offer-save is a buffer-local whereas kill-buffer-hook is a > kind of "buffer-global"; The permanent-local property only matters when the variable is buffer-local, so the fact that buffer-offer-save is always buffer-local whereas kill-buffer-hook is only sometimes so is irrelevant. > In this thread below RMS establishes a clear recipe for how he > suggest to address exactly this sort of issue: This is unrelated to buffer-offer-save. Stefan