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: Sat, 19 Jun 2010 17:20:12 +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 1276961261 23373 80.91.229.12 (19 Jun 2010 15:27:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 19 Jun 2010 15:27:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 19 17:27:38 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 1OPzxI-0004n2-SA for ged-emacs-devel@m.gmane.org; Sat, 19 Jun 2010 17:27:37 +0200 Original-Received: from localhost ([127.0.0.1]:50020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPzxH-0000HW-5G for ged-emacs-devel@m.gmane.org; Sat, 19 Jun 2010 11:27:35 -0400 Original-Received: from [140.186.70.92] (port=39245 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPzx3-0000DK-OI for emacs-devel@gnu.org; Sat, 19 Jun 2010 11:27:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPzqT-0001sS-3u for emacs-devel@gnu.org; Sat, 19 Jun 2010 11:20:34 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:62002) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPzqS-0001sI-Ua for emacs-devel@gnu.org; Sat, 19 Jun 2010 11:20:33 -0400 Original-Received: by gwj23 with SMTP id 23so1711545gwj.0 for ; Sat, 19 Jun 2010 08:20:32 -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=ichs0cq/PyrfJULIBeF1bqW/5CapqEmiXyrDaQt/Vfo=; b=lD92LQKuTgWWHyhrdWV75HaWvVeadIrl2HXchcnMPqDLNDGVEXOEt8c51i3nVYmyRM DHpsjuwbhv5SPIKDYaPVaZP+jTavJHQAPcd9Jz09/eytYob5DdkmGGvxYGyfslu6Z9wt 3mB74xXmQvh+B2C1L8GMeLtYSuOMql67kjato= 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=DIJDdE4VdJ7nO7A8GvhzI3mtM06ewgmK58rf6cKz7tiZ17ih89JkQoaf7eE+9D53Hq iaNNAEBBVZXgsScYZ0ZkuFWeeQy5dyJydGyeN0v2vsUwx7NYpL7UsM5ju+N3KR6v8PC8 F3igtUZaOmS+NLsgVa/tRmaEcavC2TqKUaqpY= Original-Received: by 10.100.244.38 with SMTP id r38mr2165320anh.29.1276960832182; Sat, 19 Jun 2010 08:20:32 -0700 (PDT) Original-Received: by 10.100.154.15 with HTTP; Sat, 19 Jun 2010 08:20:12 -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:126227 Archived-At: Sorry, I do not have time to carry on this conversation. As I said you are talking about a totally different situation. That is fine (and of course I find some of the things relevant there), but I do not have time for it. Please do not assume that I and others have not made the considerations you do. Try instead to understand our current position. (But as I said unfortunately I have no time for this now.) If you want to look into some of the more eminent parts of the difficulties with with multi major modes there are plenty of things to look into. You could for example look at the parser in nxml-mode and see if you can get it to parse non-continous parts of a buffer. On Fri, Jun 18, 2010 at 4:53 AM, MON KEY wrote: > On Thu, Jun 17, 2010 at 8:33 PM, Lennart Borgman > wrote: >>> NO! If the elisp API exposes permanent-local it isn't a misuse it is >>> to be expected that people will use it (whether you or I agree with >>> such use or not). >> >> For an OS I would agree. > > Many people consider Emacs an OS. > >> But this is a developing environment. > > Among other things. > >> There are lot of things in Emacs you can use but you should not use >> unless you know what you are doing. >> > > Thats ridiculous. Would you say you are content with those same > restrictions M$ places on their OS'. > > Would you do the same to Emacs users? > >> >> So there is nothing special with permanent-local in this regard. >> >> >>> The `misuse' of permanent-local is the ad hoc elevation of only _some_ >>> symbols to permanent local status. >>> >>> Let all symbols be permanent permanent local by default or stop adding >>> them arbitrarily to satisfy a kludge. >> >> >> It would not work. >> You would just add another non-backward complexity. > > Yes, it could create some backward incompatibilities. > > But not only could it work, it could create an interesting new > text-editor paradigm. > > I envision something not unlike Pascal Costanza's COP - Context Orient > Programming. > > Which is very interesting for the way it _is_ reliant upon and > _leverages_ dynamic scoping! Now these are some possible creative > solutions to your multiple major mode dilemas: > > :SEE (URL `http://p-cos.net/documents/contextl-soa.pdf') > :SEE (URL `http://www.jot.fm/issues/issue_2008_03/article4/') > > I think something like Costanza's ContextL _could_ be a good > compromise for Emacs-Lisp and might present a sensible route to > achieving backwards compatibility. > >> >>>> Instead, as I said before (a bit less explicit) it rather has to do >>>> with complexity. >>> >>> Nonsense, the complexity is an outcome of a series of simplistic >>> solution being thrown at the problem. >> >> >> You seem to be sure of that. > > I am. > >> Why? > > Because RMS has discussed at various points in the past why he chose > to implement Emacs Lisp with dynamic scoping and why it was a good > solution for a text-editor and text-editor scripting language. > > Because while the reasons weren't wrong or bad and were most likely > necessary at the time in order to deliver the free Emacs (and the GNU > portions he coded on that Emacs) we all know and love our prolonged > adherence to Emacs lisps dynamic scoping in the abscence of first > class lexical environments creates a can of worms that today causes us > a good many headaches. > >> To me it just looks like you are overlooking the complexity of the >> question. > > Not at all. =C2=A0I don't find the issue at hand, of itself, all that > complex. > > This said, there are a good many issues w/re Emacs' need to pass > state/values within an environment hamstrung by a language without > lexical scope. Solving any one of these issues w/ kludges is indeed > possible and Emacsen have been doing it for the 30+ years since they > crawled out of their TECO cocoon. This doesn't mean though that the > solutions have been good or `the right thing` nor does it mean that it > has always solved them in a clean, robust, reliable way that hasn't > add to an overall complexity and fragility to the system for > contemporary users to contend with. This is a complex thing. > >> >> Then just don't use libraries from authors that do not know what >> they are doing. >> > > Yes, you are right. This is a fine solution. > >> >>>> And this has nothing to do with the change I proposed. >>>> >>> Why not? >> >> There is nothing in the change I propose that makes the behavior or >> possibility of other developers different. >> > > That you think so suggests an overestimation of the viability of > the solution and validity of the problem the proposed change would > address as well as the possible good behavior of others. > >> If you think differently it suggest to me you have misunderstood the >> situation. > > :) > >> >>> Couldn't you accomplish a major-moded state change by doing >>> something like this: >> >> >> Yes. So what. > > So, if one needs certain buffers to persist state across multiple > invocations of kill-all-local-variables why is my example inferior to > your proposed change? > >> What are you trying to prove? > > That the problem which prompted your proposal doesn't (of itself) > warrant the solution. > > That one can put a plist on a local variable and frob state across > multiple major-mode changes in a reasonably transparent manner. > > That the symbols plist can remain locally permanent for a given buffer > without needing to making buffer-offer-save permanent-local. > > That one can do so without elevating the symbol to a priveleged > status. > > -- > /s_P\ >