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: Thu, 17 Jun 2010 01:11:06 +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 1276729904 18848 80.91.229.12 (16 Jun 2010 23:11:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2010 23:11:44 +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 Thu Jun 17 01:11:42 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 1OP1lj-0007tx-0z for ged-emacs-devel@m.gmane.org; Thu, 17 Jun 2010 01:11:39 +0200 Original-Received: from localhost ([127.0.0.1]:38611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP1lh-0000zN-TW for ged-emacs-devel@m.gmane.org; Wed, 16 Jun 2010 19:11:37 -0400 Original-Received: from [140.186.70.92] (port=42770 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP1la-0000uW-DD for emacs-devel@gnu.org; Wed, 16 Jun 2010 19:11:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OP1lX-0002PF-MD for emacs-devel@gnu.org; Wed, 16 Jun 2010 19:11:30 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:39065) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OP1lX-0002PA-IL for emacs-devel@gnu.org; Wed, 16 Jun 2010 19:11:27 -0400 Original-Received: by gwj23 with SMTP id 23so26267gwj.0 for ; Wed, 16 Jun 2010 16:11:26 -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=XI71z69Qr0flIRh5IIh2tQKf+MuH/CZS0NYyDdae4Pw=; b=qUHlvYU61QlegtSrGOMKiKK3ZkW7dx/E7Ogda54GAwa3PoYFCm9xTDag+T22TV4r2/ 6X1e1QctNt9cAUpc7fJoQ+dpiuPxg7IshW3SXVOJaNXnaP8hzKXruY0oKO2eKi26afhq AP5lK+ODgcAn7BEaR2ChTvGwGOWkl8AgOxKkA= 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=HjjwbgiPqPLEHKJH4PZZ7WvZJmoCSm23WI/9raspdxmXkdLfHLw7cUhY3fJ3ntDLtp jHVxw66a1FGV1M/knxVWD2nUUEgg+yFVc3gALAUHXzh/rDyg1yYQxXwWoFpNO3qamuwt J3URfOXyZQLVApMqEkhmzwYu95vTb6if6bZ6c= Original-Received: by 10.101.3.11 with SMTP id f11mr8113500ani.22.1276729886446; Wed, 16 Jun 2010 16:11:26 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Wed, 16 Jun 2010 16:11:06 -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:126044 Archived-At: On Thu, Jun 17, 2010 at 12:02 AM, MON KEY wrote: > >> 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. How do you know? What do you mean? > b) Elisp doesn't _do_ editing users do. I am glad you are aware of that ;-) > c) I'm not sure what you intend by "pure" language Ah, I see. I am far from being a language designer so I am probably using the wrong terms. What I meant is that I have seen some thoughts about how badly designed elisp is for reasons that looked to me sometimes rather decoupled from the actual merits it has when dealing with editing. (That said I can sure see there are theoretical and maintenance difficulties.) The implementation of buffer local variables has given some problems that surely was not expected from the beginning. Still I think they are necessary. And I would say the same about dynamic scoping. And even the combination of those with buffer local scope. But I can't say too much about this, I know too little. >> Those needs are sometimes hard to understand and the implementation of >> them is constantly growing. > > What needs? What understanding? What implementation? Things like those above. >> 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') It sounds fun but also a bit impractical. > `Pragmatic' is a loaded term here. ;-) > I see buffers as a core data structures living within the systems > layer somewhere alongside conventional things like lisp primitves in > the systems layer. Yes. >> 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'. You are right, it does not follow from that. But it follows from the data in the buffer is a different thing than the major mode and in most cases not dependent on the major mode. >> 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. =C2=A0without 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. =C2=A0systems 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. I think the main difficulty is that a clear picture of the interaction between the different scope rules is not given. > 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. If you see it as arbitrary I can understand that you find it problematic. But it is not arbitrary. The distinction used here is between major mode related variables (i.e. buffer local variable) and those related to buffer contents (i.e. buffer permanent local variables). > 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. It is a good concern, but actually I think a change like this makes it easier. Otherwise I would not have proposed it. > 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. No. They would not solve this problem. Those features are totally orthogonal to this problem. > 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. Again, it is really a good concern, but understanding of the architecture of the language and the environment where it is used is essential to take care of it. > 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. Did they really do that? How? > properties, `immutablity', etc. =C2=A0As 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. Hm. It is surely easier to program if you do not have to take care of all the details. But the result is perhaps that you do not take care of them either. Maybe you can explain how CL took care of the multi major buffers? > 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. Do you mean that name spaces for buffer local variables could have been used instead of the current mechanism? I am not sure. >>> 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. Which ambiguity? Do you mean buffer permanent local variables vs normal buffer local variables? It has not anything to do with major modes. It is just that certain variables are related to major modes, others are not. >> (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. I can't see how that relates to my proposal at all. If you do not like the way this things are solved in elisp then you may of course argue about that. There are things that can be made better (but the cost of making it better may far outweigh the benefits. >> 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? I did below. Why are you asking again? >>> 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. We are not discussing that. > 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? Yes, I surely can, but I feel I am wasting too much time if you do not try to do that yourself. Please come back with an example where you do this. >>> 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 conc= ern. >> - 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? If you say this is convoluted then I am not sure I want to continue the discussion. Can you give any good reason for your claim? >> Buffer content is now lost. > > Yes because we exited the program. > Don't users expect this? Of course not if they said they wanted to be asked about it. Or do you think differently? > FWIW These questions were prompted by something I read here: Yes, it is quite funny. We all know that for creative changes to start you have to have a positive and understanding environment. You have to appreciate and try to believe that you can understand the unknown further on. And you have of course to know when you do it and when you do not know it. But just stopping because you do not understand stops you from beeing creative. I would recommend the guy who solved Fermat's last theorem. He has described this in a fascinating manner. > ,---- "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? =C2=A0What 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\ >