Re: Proposal: `buffer-offer-save' be made a permanent-local

[Lennart Borgman <lennart.borgman@gmail.com>]

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 <monkey@sandpframing.com> wrote:
> On Thu, Jun 17, 2010 at 8:33 PM, Lennart Borgman
> <lennart.borgman@gmail.com> 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.  I 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\
>