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 18:02:13 -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 1276725750 6804 80.91.229.12 (16 Jun 2010 22:02:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2010 22:02:30 +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 Thu Jun 17 00:02:28 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 1OP0gm-0005sx-2V for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 00:02:28 +0200 Original-Received: from localhost ([127.0.0.1]:55054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP0gl-0002MU-9a for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 18:02:27 -0400 Original-Received: from [140.186.70.92] (port=48290 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP0gc-0002Bu-Qz for emacs-devel@gnu.org; Wed, 16 Jun 2010 18:02:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OP0ga-0007Vz-KZ for emacs-devel@gnu.org; Wed, 16 Jun 2010 18:02:18 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:63858) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OP0ga-0007Vn-HC for emacs-devel@gnu.org; Wed, 16 Jun 2010 18:02:16 -0400 Original-Received: by gwaa18 with SMTP id a18so463305gwa.0 for ; Wed, 16 Jun 2010 15:02:14 -0700 (PDT) Original-Received: by 10.150.114.2 with SMTP id m2mr10746935ybc.327.1276725734062; Wed, 16 Jun 2010 15:02:14 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Wed, 16 Jun 2010 15:02:13 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: GYvM-CjHjIzD2k790NNUD0jGj8Q 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:126042 Archived-At: On Wed, Jun 16, 2010 at 7:39 AM, Lennart Borgman wrote: > On Wed, Jun 16, 2010 at 9:21 AM, MON KEY wrote: >> On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman >> wrote: > > So, can we then perhaps say that this discussion has very little to do > with the proposal I made? No, I am not saying that. > This discussion seems to me much more general. I'm still in the realm between items 2 and 3 of your taxonomy. If there is a generality to be explored it is w/re a design decision and the distinction being made about state of a buffer's data not about the language (e.g. the code/data dichotomy). > > 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. > a) Your characterization of what is `needed' is a false choice. b) Elisp doesn't _do_ editing users do. c) I'm not sure what you intend by "pure" language > Those needs are sometimes hard to understand and the implementation of > them is constantly growing. What needs? What understanding? What implementation? > It is necessarily a pragmatic approach as I understand it. There are of course different understandings of `pragmatism' :-) FWIW I don't ascribe to the `Worse is Better' school of pragmatism e.g. :SEE (URL `http://www.jwz.org/doc/worse-is-better.html') :SEE (URL `http://en.wikipedia.org/wiki/Worse_is_better') > >> 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. > > I would say that so far we are in the concepts of a "pure" language. Whatever. It is the realm of constraints and their satisfaction. > >> 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. `Pragmatic' is a loaded term here. The distinction is prob. better characterized as follows: Emacs is a form of operating system and has (among others): - a systems-programming layer; - an application-programming layer; Where systems-programming is concerned with the core data structures, the primitives operating upon them, and the formalism by which this can/should occur; the application-programming layer is concerned with the abstract interfaces to these data structures and the semantics by which we interact with them. I see buffers as a core data structures living within the systems layer somewhere alongside conventional things like lisp primitves in the systems layer. I see user elisp commands, functions, major-modes, instantiated variables etc. as living in the application layer. The point of contact between these two layers intersects at the users buffer-content as manipulated by the dialect of Lisp that Emacs implements. > Buffer local variables is in my opinion a nice way to handle the > needs specific to editing specific buffer. Of course they are. However, it doesn't necessarily hold then that _variables_ (buffer-local and otherwise) by virtue of their applicability to a specific editing need and/or the specific buffer(s) utilized to meet such needs be therefor afforded an escalated status because it is a `nice way to handle these needs'. > 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). Questions of pragmatism aside, the determination of `problematic' is most likely relative to the current `conceptual layer' one is concerned with, e.g. systems layer vs. appliciation layer >From the application-programming perspective it is absolutely a pain coordinating variable values across different application states. Indeed, it is often made more difficult _because_ the Emacs systems layers has been allowed a variably dynamic perspective w/re _how_ a variable is global. What I find problematic is that the escalation of certain variables to a privelged buffer local status (in this case making buffer-offer-save a permanent-local) seems ad-hoc with the determination made according to some arbitrary assement of application-programmer need. Of itself there prob. isn't anything right or wrong with such decisions. Where I think they are problematic is that this type of pragmatism can cummulatively make it more difficult to implement systematic changes at the systems layer. For example, WIBN to have first class lexical-binding and package-level namespacing. Each of these could (indeed should) be made features of the buffer at the systems level and then be made implicilty accesible at the application layer level and would solve both the buffer-offer-save problem and many others. AFAICT this is not the direction that is or has been taken and so it becomes increasingly difficult to implement them because ad hocery is not easily undone. While it is prob. _never_ gonna be retro-fitted onto Emacs lisp, AIUI the Common-Lisp or FTM MacLisp package systems accomplish(ed) much of what we are now trying to accomplish with buffers and (multiple)major-modes. Too bad. > 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. Please don't mistake my concern over the escalation of buffer-local variable permanence by construing that I hold that buffer-local-variables are `bad'. This is not at all the case. > But the logic for variable scope is a bit less clear with it. It is less clear only in lieu of vacuous or informal specification. > >> 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 No. This is not what I mean to say. I am saying that the assignement of exceptional behaviour is arbitrary, that while any symbol _can_ be made buffer-local, permanent-local, etc. only some have been made so such that the historically conventioal Lisp special-operators and the standard/core Elisp procedures will react to their prescence, properties, `immutablity', etc. As these types of exceptions affect (and are affected by) the application layer programmer I think it would be better to simply make a clean break by making all Emacs variables (either the let bound or the global variety) be both permanent and local to a buffer. Of course something such as this would amount to some sort of equivalent to the Common-Lisp/Maclisp package system... > (those are not deleted when changing major mode and we call them for > historical reason permanent local in a buffer). Historically speaking I think this is kludged packaging/namespacing that so happens to have become a factor of and for the need for major modes to exist with a semi-privelged status. >> 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". > No. The ambiguity that affects major modes does so as a side effect. > And if you say that those things can not always be clearly distinguish > then I agree. I don't agree at all. It is absolutely possible to formalize -- just increasingly difficult/tedious in the face of ad hocism. FWIW a good example of what happens in the absence of clarity w/re these issues one need only look at the W3C's CSS and the ongoing attempts to maintain a formal specification with a grammar/syntax that has been bent over backward to accomodate various whims of application layer ad hocery. > (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".) One can certainly argue that it is either. I'm suggesting it should be both. I'm also suggesting that in order for it to be so, these decisions have to be made at the systems layer in order to formally declare and specify a scheme by which "buffer things" and "major mode things" are able to permanently (or at least indefinitely) _own_ all of "their things" as opposed to owning just some of them until fate or the "gods of pragmatic dynamism" take them away. > >> 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. > Yes, well... "anything else" is the paragon of clarity and simplicty we have now :P > >> 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. Can you provide a specific recipe for this? Perhaps a Elisp code formula that one can replay to illustrate what happens? >> How is it envisioned it shall be implemented in solving those >> problems? > > Just make buffer-offer-save permanent buffer local. That doesn't describe how an implementation will implement the change this is a description of how the change will be implemented. Can you provide an example of an existing piece of code which can advantageously be made to use the proposed change and provide an example of such usage? > >> 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. > That seems like a convoluted scenario to be sure. Why is the user evaluating a `setq' when she could just do C-x C-s if that is what is wanted? > Buffer content is now lost. Yes because we exited the program. Don't users expect this? FWIW These questions were prompted by something I read here: ,---- "Standards, the Net and All That" interview w/ Larry Masinter | | We had a document that we were starting with and people wanted to | propose changes to it. The form had on it, the first part of the | form was the problem statement - you had to say what was wrong | with the language, what was wrong? What was the problem you were | trying to solve without describing your proposal for how you were | going to fix it. That was very difficult for some people. It was a | good filter for - there is this neat feature that we need, because | you had to describe what functions this feature filled before you | told people what the feature was. The second part of the form was | your proposal, what you were proposing to do which you had to | describe without arguing for it. You couldn't say, 'there is this | great feature, add this following wonderful thing.' You had to | say, ' add this following thing' without any positive | adjectives. There was no arguments. Then there were these sections | about costs where you had to say what it would cost to users if | you added this or made this change, what would it cost to | implementers in order to implement it, and what were the benefits | for users and implementers, and so on. What was the performance | implication, what is current practice, what did other people do? | And on the bottom there was discussion where you could put all of | the war stories, all of the testimonials, the statement that this | following famous figure in the list community likes this feature. | `---- :SEE (URL `http://www.almaden.ibm.com/almaden/npuc97/1996/tmasinter.htm') -- /s_P\