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: Wed, 16 Jun 2010 03:21:41 -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 1276672945 3274 80.91.229.12 (16 Jun 2010 07:22:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2010 07:22:25 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 16 09:22:22 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 1OOmx3-0006M5-PW for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 09:22:22 +0200 Original-Received: from localhost ([127.0.0.1]:52811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOmx2-0006yL-IV for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 03:22:21 -0400 Original-Received: from [140.186.70.92] (port=54162 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOmwU-0006wv-S9 for emacs-devel@gnu.org; Wed, 16 Jun 2010 03:21:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOmwS-0000op-U2 for emacs-devel@gnu.org; Wed, 16 Jun 2010 03:21:46 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:44351) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOmwS-0000oT-Re for emacs-devel@gnu.org; Wed, 16 Jun 2010 03:21:44 -0400 Original-Received: by gwj21 with SMTP id 21so606869gwj.0 for ; Wed, 16 Jun 2010 00:21:44 -0700 (PDT) Original-Received: by 10.151.92.14 with SMTP id u14mr10078136ybl.45.1276672901785; Wed, 16 Jun 2010 00:21:41 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Wed, 16 Jun 2010 00:21:41 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: XsoD7pQxeRaNF5TgNTOcTlucs3k 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:125993 Archived-At: On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman wrote: > discussion we can think of variable scope versus buffers in a > hierarchy like this: > > 1) * global variable values > 2) ** buffer local variable that are permanently local > 3) *** buffer local variable that are not permantly local Thanks, but that didn't really help. :-) I guess I don't understand why this is the distinction being made and in this manner. It seems conflated to further mix up a variable's scope with its extent in this way. What I thought I knew: Emacs/Emacs-lisp has variables that are always global. A variable is an object accessible as symbol instantiated via defvar, defconstant, set, setq, fset, etc. These can be dynamically bound via let, let*,lambda, condition-case etc. and have dynamic scope. How a variable value exists(or doesn't) does not affect its scope. Whether a variable is bound as a property of a buffer (e.g. with a specific locality/place) it still has a scope which the standard operators can access, bind, and void. These conventional behaviours have been made to act exceptionally if a variable is both buffer-local and permanent (e.g. by making the variable locally buffer immutable). As Stefan hinted, and as I concurred, I'm not at all adverse/concerned with variables being permanent-local it's the selectivity that bothers me b/c it guarantees difficulty for others in knowing the if, when, how, why a variable is being acted upon (or isn't). It seems unclean to make some variables permanent local and others not esp. as we don't have a specification to help resolve an ambiguity (which BTW is why I believe some concern over this is justified). Are the rules for variable buffer locality arbitrary? Where is the documentation for proper/idiomatic use of permanent-local variable. I ask this because I'm unable to find a reference to the `permanent-local-hook' though it _does_ exist. What should others understand about the proposed change? What specific problems does it solve? What happens if the proposed change is not implemented. How is it envisioned it shall be implemented in solving those problems? Where is some code to illustrate an idiomatic use-case for the proposed change?. -- /s_P\