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: Mon, 14 Jun 2010 04:48:12 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1276505304 21629 80.91.229.12 (14 Jun 2010 08:48:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 08:48:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 14 10:48:23 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 1OO5LC-0006ri-Ic for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 10:48:22 +0200 Original-Received: from localhost ([127.0.0.1]:56021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO5LB-000818-Sf for ged-emacs-devel@m.gmane.org; Mon, 14 Jun 2010 04:48:21 -0400 Original-Received: from [140.186.70.92] (port=57633 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO5L5-00080m-1e for emacs-devel@gnu.org; Mon, 14 Jun 2010 04:48:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OO5L3-0006zg-II for emacs-devel@gnu.org; Mon, 14 Jun 2010 04:48:14 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:35160) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO5L3-0006zX-Ef for emacs-devel@gnu.org; Mon, 14 Jun 2010 04:48:13 -0400 Original-Received: by gyg4 with SMTP id 4so2620464gyg.0 for ; Mon, 14 Jun 2010 01:48:12 -0700 (PDT) Original-Received: by 10.151.25.16 with SMTP id c16mr6126300ybj.363.1276505292178; Mon, 14 Jun 2010 01:48:12 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Mon, 14 Jun 2010 01:48:12 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: G3TGGBXihkHuPl3aho5w0Efpw_g 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:125896 Archived-At: On Sun, Jun 13, 2010 at 9:00 PM, Stefan Monnier wrote: > 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? > The uses where buffer-offer-save would need to be permanent-local are > uses where this state is not bound to a major-mode. > Again, if this is the only issue/use-case why not then just put it on the kill-buffer-hook? > 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? Would anyone care to venture a guess as to the percentage of these major-modes that do expect change vs those that don't (in Emacs and third party code)? > > 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**; - buffer-offer-save is a buffer-local whereas kill-buffer-hook is a kind of "buffer-global"; - kill-buffer-hook is well... a hook variable (and all this implies); **Are there any known examples of a binding of the the buffer-offer-save variable w/ a value as a sequence, symbol-function, etc.? In this thread below RMS establishes a clear recipe for how he suggest to address exactly this sort of issue: ,---- | Here's a possible implementation. | | 1. Put a property on hook variables to identify them for this | special processing. | | 2. Put another property (as you suggested) on hook functions | to indicate they should be preserved. | | 3. Now it is possible for kill-all-local-variables | to identify hook variables, scan their local values, | and preserve specific hooks. `---- http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00366.html Of itself this is merely a possible approach to the problem. However, it is important to note that RMS followed through on his suggested solution by stating that: ,---- | I think it is very unclean to dynamically change `permanent-local' | properties. That's the sort of thing that we are sure to regret. | | We should use my mechanism instead. It is simple and clean. `---- http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00510.html So, what is wrong with the solution RMS proposed. It is worth noting that src/ChangeLog shows: RMS acting on this change circa 2008-01-25 : ,---- | * buffer.c (reset_buffer_local_variables): | Implement `permanent-local-hook'. | (Qpermanent_local_hook): New variable. | (syms_of_buffer): Init and staticpro it. `---- What other attempts have been made to incorporate/verify this solution? > > 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. Yes. I hadn't really considered this line of asymmetric reasoning because it doesn't seem reasonable unless there is an option to universally choose/define special variables independently *and* in the stead of an otherwise equivalently set of default lexical variables... which is not at all the case with current emacs lisp. IOW just because we know that the set of variables need not necessarily be permanent-local doesn't of itself mean we can actually do much useful with that information we're just swapping vacuity. > 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. I'm under the impression that this was originally _by design_. > So your general argument might end up arguing in favor of making all > variables permanent-local. Indeed, this is very much the case and I would welcome such a change. It is required for the transition to lexical scope no? So, are you intent on the proposed change becoming the harbinger for such a shift or is it to become just another finger in the dijk? > Stefan /s_P\