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: Wed, 16 Jun 2010 13:39:37 +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 1276688416 25712 80.91.229.12 (16 Jun 2010 11:40:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2010 11:40:16 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 16 13:40:14 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 1OOqyc-0002Hh-0K for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 13:40:14 +0200 Original-Received: from localhost ([127.0.0.1]:42847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOqyb-0007GF-3T for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 07:40:13 -0400 Original-Received: from [140.186.70.92] (port=51699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOqyN-0007Cz-Nn for emacs-devel@gnu.org; Wed, 16 Jun 2010 07:40:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOqyM-0004UJ-5E for emacs-devel@gnu.org; Wed, 16 Jun 2010 07:39:59 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:57991) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOqyM-0004UE-0p for emacs-devel@gnu.org; Wed, 16 Jun 2010 07:39:58 -0400 Original-Received: by gwj21 with SMTP id 21so689333gwj.0 for ; Wed, 16 Jun 2010 04:39:57 -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=AgNi+SZ9A4mVJABmM0S/EG/weyG4undsSVqHhQ+xF58=; b=VcnST7tVBA/5Y3j1SdcJr1jeA3wWKvH3VZAVdaas+Ge3zV1NONXTWwdYPs91Rhd91K 3+nMCwlapf/asYtW7pnHqFzRLdr9d7i9DRs2fzvzTlYUnmU2DC6uD/gjtzU0EGUtgRZo KKVKJNY1aDsEeoXp2ZPKI5upCtqfKeizQ0vEY= 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=n+WUQ/F5SfnIgivKIgwyucMOSB9FsCHOrc3qDwwWQQoAVGtu7mTaniAxmHV4mY2w+S 2y2ZImFSrabB2d5lCTf3CqRGnCVDvc1wyBCUGMU4FDjBLoLK6x8C4U6X8gE76fOR4Iyz 0O19rzd8gayLvyIBJN87NF+cBMs349+XXOkbI= Original-Received: by 10.101.210.31 with SMTP id m31mr6991611anq.205.1276688397157; Wed, 16 Jun 2010 04:39:57 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Wed, 16 Jun 2010 04:39:37 -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:125999 Archived-At: On Wed, Jun 16, 2010 at 9:21 AM, MON KEY wrote: > 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. :-) That is not too bad since it gets us a step further. So, can we then perhaps say that this discussion has very little to do with the proposal I made? This discussion seems to me much more general. > I guess I don't understand why this is the distinction being made and > in this manner. =C2=A0It seems conflated to further mix up a variable's > scope with its extent in this way. I guess what is at the center of the discussion is what is needed for elisp to support the editing needs versus a "pure" language that is does not have to do things like that. Those needs are sometimes hard to understand and the implementation of them is constantly growing. It is necessarily a pragmatic approach as I understand it. > 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. =C2=A0How a variable value exists(or doesn't= ) > does not affect its scope. I would say that so far we are in the concepts of a "pure" language. > 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. Yes. But now we are approaching the pragmatic part of it as I see it. Buffer local variables is in my opinion a nice way to handle the needs specific to editing specific buffer. However "scope" now suddenly has a little bit different meaning and it is a bit problematic coordinating the buffer locality with the "old" type of scope (i.e. without buffer locality). Personally I can't even imagine how to write an editor with Emacs capabilities without buffer local variables so I think it is a good thing. But the logic for variable scope is a bit less clear with it. (So far we have not touched those difficulties, but since you mention scope I thought it might be good to say this.) > 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). I think you mean the difference between buffer local variables that handle major mode things (those are deleted and maybe set to new values when changing major mode) and those that handle buffer things (those are not deleted when changing major mode and we call them for historical reason permanent local in a buffer). > 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). Yes, I have understood that. > 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 I think this ambiguity is exactly what I describe above as "major mode things" versus "buffer things". And if you say that those things can not always be clearly distinguish then I agree. (Here we are back at my proposal. The essence of it is that I think that buffer-offer-save is more a "buffer thing" than a "major mode thing".) > (which BTW is why I believe some concern over this is justified). Are > the rules for variable buffer locality arbitrary? Not conceptually but it is sometimes in practice difficult to distinguish "major mode things" from "buffer things" since they are more coupled in some circumstances. > Where is the > documentation for proper/idiomatic use of permanent-local variable. There can be no such. It is by necessity a pragmatic approach. Anything else would make things terribly complex in my opinion. I do not know if others agree, but a description somewhat like the one I have given above is the closest you can come. (You can go further into details, of course.) > What should others understand about the proposed change? > > What specific problems does it solve? Users may loose data (whole buffers actually) if buffer-offer-save is erased by a major mode change and the user is unaware of this. > What happens if the proposed change is not implemented. See above. > How is it envisioned it shall be implemented in solving those > problems? Just make buffer-offer-save permanent buffer local. > Where is some code to illustrate an idiomatic use-case for the > proposed change?. Here: - User does in some way (setq buffer-offer-save t) in the buffer of concern= . - Later *he does a major mode switch in this buffer. - Exit Emacs. Buffer content is now lost.