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

[MON KEY <monkey@sandpframing.com>]

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\