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

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

[MON KEY]

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

Recently there was a proposal on bug-gnu-emacs to have
`buffer-offer-save' be made a permanent-local e.g.
 "bug#6241: Please make buffer-offer-save permanent local"
in which Stefan expressed some willingness to endorse the change:

,----
|  { ... } it's easier to circumvent an annoying permanent-local than
| it is to fake one.  I.e. if a var is permanent-local and you need it
| to be killed by kill-all-local-variables, you can do something like:
|
|  (add-hook 'change-major-mode-hook
|            (lambda () (kill-local-variable 'foobar)))
|
| whereas if it is not permanent-local and you need it to survive a
| change of major-mode, you have to jump through a few more hoops (a
| change-major-mode-hook to stash the variable's content somewhere,
| plus an after-change-major-mode-hook to reset it after the fact,
| plus additional code to handle the case when
| after-change-major-mode-hook is not run, ...).
|
| So, now that the question of "should it ideally be permanent-local?"
| is resolved, the remaining question is: "what would be the impact of
| such a change", which requires examining all uses of the variable
| and assessing the effect of the change for each case.
`----
 http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00730.html

I requested that this decision be discussed/proposed to emacs-devel b/c
it struck me as both a potentially breaking change and one that isn't
needed. To date, this discussion hasn't happened.

So, what do others here think?

Is this proposed changed needed, desirable, welcome?

IIUC Stefan's rationale for consideration of making
`buffer-offer-save' permanent-local is that it would ease the burden
placed on major-modes (and their authors) to set/check for the
presence of `buffer-offer-save' by making the value a permanent
property of every Emacs buffer not yet visiting a file such that a
major-mode/feature would now be able to set `buffer-offer-save' as a
`buffer-local-value' and thereafter rely on the value persisting
across multiple subsequent invocations of the
`kill-all-local-variables'->`change-major-mode-hook' call chain.

Consideration of following exchange which transpired between RMS and
Stefan on emacs-devel circa 2003-06-01 as thread:
 "Re: kill-buffer-hook permanent-local"
has caused me some doubt as to whether the current proposed change is
TRT and is in keeping with the rationale for other similar such
changes in the past:

,----
| Stefan Monnier:
| >> Shouldn't kill-buffer-hook be permanent-local ?
|
| RMS:
| > I think it is OK to make this change.
| > If a certain major mode wants to set up a hook value
| > that should not remain if you change the mode, it could
| > use change-major-mode-hook to remove that hook.
`----
 http://lists.gnu.org/archive/html/emacs-devel/2003-06/msg00066.html

My impression is that `kill-all-local-variables' is generally relied
upon to restore/reset a buffer to a more or less default state and
then evaluates `change-major-mode-hook' to begin the process of
introducing/enabling the variables and behaviors which are
peculiar/relevant on entrance to a particular major-mode e.g.:

 (describe-variable 'change-major-mode-hook)

,----
| Normal hook run before changing the major mode of a buffer.  The
| function `kill-all-local-variables' runs this before doing anything
| else.
`----

What I don't understand is, why if `kill-buffer-hook' is
permanent-local (which it now is), and calls to
`kill-all-local-variables' automatically evaluate
`change-major-mode-hook' do we now also need to have
`buffer-offer-save' be made permanent-local?

IIUC, RMS seems to be saying above that his caveat for allowing
`kill-buffer-hook' as a permanent-local was _because_ it could be
removed/altered/overridden by subsequent calls to
`change-major-mode-hook'.  In contrast, the currently proposed change
to have `buffer-offer-save' become permanent-local is essentially an
attempt to circumvent the same exceptional behavior which RMS seems
to suggest convinced him that it was reasonable to allow
`kill-buffer-hook' as a permanent-local.

As currently proposed this new permanent-local will mean that
major-modes will now have to explicitly check for the
`buffer-local-value' of `buffer-offer-save' whereas up until now
major-mode authors could assume it to be nil being that it was
automatically zapped by `kill-all-local-variables' before the any
further major-mode changes occurred.

IME most buffers rarely require more than three distinct major-modes
to reasonably edit the text within context. So, I personally don't
understand what problem the proposed change solves. It doesn't seem
like that big a deal for a particular major-mode to check for the
value of variable if it is necessary for it to do so in order to
reasonably satisfy user expectations.

To the extent that the change is needed/wanted/desirable,
why can't a mode-local `buffer-offer-save' be added to the
`kill-buffer-hook' instead to accomplish the same goal of making
`buffer-offer-save' permanent-local without having to add an
additional atomic and effectively immutable global to every buffer's
list of `buffer-local-variables'?

Does the proposed change offer the right level of granularity for a
variable which globally affects the effective state of buffer
savedness?

Should `buffer-offer-save' be allowed to become a permanent-local
property of a buffer it may indeed solve what is at present a
relatively minor and esoteric issue affecting a few developers of
certain major-modes whose features require programatically
enabling/disabling the mode multiple times during the life of a buffer
to accomplish complicated presentation tasks.

My concern, is that though the issue doesn't currently seem to
adversely affect the development of most major-modes this doesn't mean
that if/once buffer-offer-save is made permanent-local it won't be
bound more often via the `change-major-mode-hook' in the wild by third
party code. Should this occur it may well violate many user
expectations placing a burden on the _user_ to find and remove any
inadvertent binding of this global property hidden away in a dedicated
package function/macro. Right now this isn't a problem for users
because the buffer-offer-save property is typically bound/removed with
each call to `kill-all-local-variables'->`change-major-mode-hook' on a
mode-change.

One argument which has been made for making `buffer-offer-save'
permanent-local is that this value reflects aspects of a buffers
textual content whereas the current situation treats it as part of a
buffer's major-mode context.

IOW Currently it is left to the buffer's major-mode (context) to
determine on each mode-change whether an unsaved buffer in that mode
should require that Emacs always offer to save the buffer on
exit. However, if I should change from `emacs-lisp-mode' to
`scheme-mode' the the text/chars the buffer contains (content) don't
necessarily change, the decision of whether Emacs will offer to save
the buffer is now decided by the `scheme-mode' context.

I like the current behavior, I find it intuitive, and generally for a
given buffer I know how Emacs will respond according to what the
mode-line displays about the state of a given buffers major-mode. I'm
comfortable knowing that when I'm in comint-mode buffer I'm gonna get
an entirely different set of behaviors than when I'm in `org-mode'.

I am adverse to making buffer-offer-save permanent-local because:
 - It treats the users choice of major-modes (context) as 2nd class;
 - Elevates buffer characters to vi modal status;
 - Abstracts and/or removes a user interface for controlling/monitoring
   a fundamental bit of Emacs behavior (buffer savedness);
 - May violate user notions of whether or not a buffer is treated by
   default as optionally expendable or inherently immutable.

IMHO Emacs is better served moving _away_ from permanent-locals and
other sorts of heavy-handed globals with an implicit reliance on
dynamic-scoping and instead seek to find/incorporate first-class
lexical-scoping solutions which can better accommodate both the user
and package developers.

Related Background:

http://lists.gnu.org/archive/html/emacs-devel/2003-06/msg00025.html
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00169.html
http://article.gmane.org/gmane.emacs.devel/82069
http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00364.html

--
/s_P\

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

[Lennart Borgman]

On Mon, Jun 14, 2010 at 2:17 AM, MON KEY <monkey@sandpframing.com> wrote:
> Proposal: `buffer-offer-save' be made a permanent-local.
>
> Recently there was a proposal on bug-gnu-emacs to have
> `buffer-offer-save' be made a permanent-local e.g.
>  "bug#6241: Please make buffer-offer-save permanent local"
> in which Stefan expressed some willingness to endorse the change:


It was my proposal and we discussed it quite a bit here:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6241

The rationale for the proposal is that if a user somehow sets
buffer-offer-save to t it should not be lost because the user changes
major mode.

The content of the buffer is a propriety of the user, not the major mode.

The only real objection to this is that there can be corner cases
where a major mode relies on the current behavior. I suggest that this
if this is a problem then we will surely here of it and can easily fix
it.

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

[Stefan Monnier]

> IIUC Stefan's rationale for consideration of making
> `buffer-offer-save' permanent-local is that it would ease the burden
> placed on major-modes (and their authors) to set/check for the
> presence of `buffer-offer-save' by making the value a permanent

No.  If buffer-offer-save is bound to a major-mode, then it should not
be permanent-local (i.e. if that variable is permanent-local, then the
major-mode will need to use change-major-mode-hook to kill that var
explicitly).
The uses where buffer-offer-save would need to be permanent-local are
uses where this state is not bound to a major-mode.

AFAICT, all current uses of buffer-offer-save in Emacs are in places
where the major-mode is not expected to change and where, in case it
does change, it doesn't matter much what happens anyway.

> Consideration of following exchange which transpired between RMS and
> Stefan on emacs-devel circa 2003-06-01 as thread:
>  "Re: kill-buffer-hook permanent-local"
> has caused me some doubt as to whether the current proposed change is
> TRT and is in keeping with the rationale for other similar such
> changes in the past:

The exchange explains how making kill-buffer-hook permanent-local is not
too terrible, because specific major-modes can override the permanence
via change-major-mode-hook.  That same argument applies to any variable,
including buffer-offer-save.

> IMHO Emacs is better served moving _away_ from permanent-locals and
> other sorts of heavy-handed globals with an implicit reliance on
> dynamic-scoping and instead seek to find/incorporate first-class
> lexical-scoping solutions which can better accommodate both the user
> and package developers.

While the permanent-local property is global, it doesn't mean that it's
bad in the same sense as a global variable.  More specifically, the fact
that a variable is not permanent-local, is *also* a global property.
And while a permanent-local variable can easily be made non-permanent
via change-major-mode-hook, it is a lot more difficult to reliably make
a non-permanent-local variable permanent.
So your general argument might end up arguing in favor of making all
variables permanent-local.


        Stefan

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

[MON KEY]

On Sun, Jun 13, 2010 at 9:00 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> No.  If buffer-offer-save is bound to a major-mode, then it should not
> be permanent-local (i.e. if that variable is permanent-local, then the
> major-mode will need to use change-major-mode-hook to kill that var
> explicitly).

So, the burden is shifted from major-mode authors and users to check/test for
the property where the check has not otherwise been explicitly required of
either in the past?

> The uses where buffer-offer-save would need to be permanent-local are
> uses where this state is not bound to a major-mode.
>
Again, if this is the only issue/use-case why not then just put it on the
kill-buffer-hook?

> AFAICT, all current uses of buffer-offer-save in Emacs are in places
> where the major-mode is not expected to change and where, in case it
> does change, it doesn't matter much what happens anyway.

So, is it fair to assume that for these major-mode's which are not expected to
change there is no particular benefit/gain of having buffer-offer-save
permanent-local?

Would anyone care to venture a guess as to the percentage of these
major-modes that do expect change vs those that don't (in Emacs and third
party code)?

>
> The exchange explains how making kill-buffer-hook permanent-local is not
> too terrible, because specific major-modes can override the permanence
> via change-major-mode-hook.  That same argument applies to any variable,
> including buffer-offer-save.
>

Maybe, but they don't necessarily apply in the same way though b/c:

 - buffer-offer-save is a boolean**;

 - buffer-offer-save is a buffer-local whereas kill-buffer-hook is a
   kind of "buffer-global";

 - kill-buffer-hook is well... a hook variable (and all this implies);

    **Are there any known examples of a binding of the the
      buffer-offer-save variable w/ a value as a sequence,
      symbol-function, etc.?

In this thread below RMS establishes a clear recipe for how he
suggest to address exactly this sort of issue:

,----
|  Here's a possible implementation.
|
|  1. Put a property on hook variables to identify them for this
|  special processing.
|
|  2. Put another property (as you suggested) on hook functions
|  to indicate they should be preserved.
|
|  3. Now it is possible for kill-all-local-variables
|  to identify hook variables, scan their local values,
|  and preserve specific hooks.
`----
 http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00366.html

Of itself this is merely a possible approach to the problem. However,
it is important to note that RMS followed through on his suggested
solution by stating that:

,----
| I think it is very unclean to dynamically change `permanent-local'
| properties.  That's the sort of thing that we are sure to regret.
|
| We should use my mechanism instead.  It is simple and clean.
`----
 http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00510.html

So, what is wrong with the solution RMS proposed.

It is worth noting that src/ChangeLog shows:
RMS  acting on this change circa 2008-01-25 :

,----
| * buffer.c (reset_buffer_local_variables):
| Implement `permanent-local-hook'.
| (Qpermanent_local_hook): New variable.
| (syms_of_buffer): Init and staticpro it.
`----

What other attempts have been made to incorporate/verify this
solution?

>
> While the permanent-local property is global, it doesn't mean that it's
> bad in the same sense as a global variable.  More specifically, the fact
> that a variable is not permanent-local, is *also* a global property.

Yes. I hadn't really considered this line of asymmetric reasoning
because it doesn't seem reasonable unless there is an option to
universally choose/define special variables independently *and* in
the stead of an otherwise equivalently set of default lexical
variables... which is not at all the case with current emacs
lisp. IOW just because we know that the set of variables need not
necessarily be permanent-local doesn't of itself mean we can
actually do much useful with that information we're just swapping
vacuity.

> And while a permanent-local variable can easily be made non-permanent
> via change-major-mode-hook, it is a lot more difficult to reliably make
> a non-permanent-local variable permanent.

I'm under the impression that this was originally _by design_.

> So your general argument might end up arguing in favor of making all
> variables permanent-local.

Indeed, this is very much the case and I would welcome such a change.
It is required for the transition to lexical scope no?
So, are you intent on the proposed change becoming the harbinger for
such a shift or is it to become just another finger in the dijk?

>  Stefan

/s_P\

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

[Lennart Borgman]

On Mon, Jun 14, 2010 at 10:48 AM, MON KEY <monkey@sandpframing.com> wrote:
>
> In this thread below RMS establishes a clear recipe for how he
> suggest to address exactly this sort of issue:
>
> ,----
> |  Here's a possible implementation.
> |
> |  1. Put a property on hook variables to identify them for this
> |  special processing.
> |
> |  2. Put another property (as you suggested) on hook functions
> |  to indicate they should be preserved.
> |
> |  3. Now it is possible for kill-all-local-variables
> |  to identify hook variables, scan their local values,
> |  and preserve specific hooks.
> `----
>  http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00366.html


No. This is for a more complicated problem.

It might be more easy to understand with a small picture. In this
discussion we can think of variable scope versus buffers in a
hierarchy like this:

1) * global variable values
2) ** buffer local variable that are permanently local
3) *** buffer local variable that are not permantly local

3, the lowest level are variables associated with major modes. If
there are several major modes in a buffer those variable will change
with the point in the buffer.

2 are the buffer level. Those variable are associated with the buffer
instead of the major mode. If the major mode is changed the
permanently local does not change. They never change with the point in
the buffer.


The situation that RMS tried to handle was when a hook variable was
local and some members of it should be independent of the major mode,
but not the whole list of variables in the hook. This is something in
between 2 and 3 above.


> | I think it is very unclean to dynamically change `permanent-local'
> | properties.  That's the sort of thing that we are sure to regret.


That is what we are trying to avoid by making buffer-offer-save
permanently local.


> So, what is wrong with the solution RMS proposed.


Nothing, but it does not fit here.

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

[MON KEY]

On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> discussion we can think of variable scope versus buffers in a
> hierarchy like this:
>
> 1) * global variable values
> 2) ** buffer local variable that are permanently local
> 3) *** buffer local variable that are not permantly local

Thanks, but that didn't really help. :-)

I guess I don't understand why this is the distinction being made and
in this manner.  It seems conflated to further mix up a variable's
scope with its extent in this way.

What I thought I knew:

Emacs/Emacs-lisp has variables that are always global.

A variable is an object accessible as symbol instantiated via defvar,
defconstant, set, setq, fset, etc.

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.

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.

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).

As Stefan hinted, and as I concurred, I'm not at all adverse/concerned
with variables being permanent-local it's the selectivity that bothers
me b/c it guarantees difficulty for others in knowing the if, when, how, why a
variable is being acted upon (or isn't).

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
(which BTW is why I believe some concern over this is justified). Are
the rules for variable buffer locality arbitrary? Where is the
documentation for proper/idiomatic use of permanent-local variable.  I
ask this because I'm unable to find a reference to the
`permanent-local-hook' though it _does_ exist.

What should others understand about the proposed change?

What specific problems does it solve?

What happens if the proposed change is not implemented.

How is it envisioned it shall be implemented in solving those
problems?

Where is some code to illustrate an idiomatic use-case for the
proposed change?.

--
/s_P\

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

[Lennart Borgman]

On Wed, Jun 16, 2010 at 9:21 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> discussion we can think of variable scope versus buffers in a
>> hierarchy like this:
>>
>> 1) * global variable values
>> 2) ** buffer local variable that are permanently local
>> 3) *** buffer local variable that are not permantly local
>
> Thanks, but that didn't really help. :-)

That is not too bad since it gets us a step further.

So, can we then perhaps say that this discussion has very little to do
with the proposal I made? This discussion seems to me much more
general.

> I guess I don't understand why this is the distinction being made and
> in this manner.  It seems conflated to further mix up a variable's
> scope with its extent in this way.

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.

Those needs are sometimes hard to understand and the implementation of
them is constantly growing. It is necessarily a pragmatic approach as
I understand it.

> What I thought I knew:
>
> Emacs/Emacs-lisp has variables that are always global.
>
> A variable is an object accessible as symbol instantiated via defvar,
> defconstant, set, setq, fset, etc.
>
> 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.

> 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.

Buffer local variables is in my opinion a nice way to handle the needs
specific to editing specific buffer. 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).

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. But the logic for variable scope is a bit less clear with it.
(So far we have not touched those difficulties, but since you mention
scope I thought it might be good to say this.)

> 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
(those are not deleted when changing major mode and we call them for
historical reason permanent local in a buffer).

> As Stefan hinted, and as I concurred, I'm not at all adverse/concerned
> with variables being permanent-local it's the selectivity that bothers
> me b/c it guarantees difficulty for others in knowing the if, when, how, why a
> variable is being acted upon (or isn't).

Yes, I have understood that.

> 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".

And if you say that those things can not always be clearly distinguish
then I agree. (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".)

> (which BTW is why I believe some concern over this is justified). Are
> the rules for variable buffer locality arbitrary?

Not conceptually but it is sometimes in practice difficult to
distinguish "major mode things" from "buffer things" since they are
more coupled in some circumstances.

> 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.

I do not know if others agree, but a description somewhat like the one
I have given above is the closest you can come. (You can go further
into details, of course.)

> 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.

> What happens if the proposed change is not implemented.

See above.

> How is it envisioned it shall be implemented in solving those
> problems?

Just make buffer-offer-save permanent buffer local.

> 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.

Buffer content is now lost.

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

[MON KEY]

On Wed, Jun 16, 2010 at 7:39 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Jun 16, 2010 at 9:21 AM, MON KEY <monkey@sandpframing.com> wrote:
>> On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman
>> <lennart.borgman@gmail.com> 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\

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

[Lennart Borgman]

On Thu, Jun 17, 2010 at 12:02 AM, MON KEY <monkey@sandpframing.com> 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.  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.

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.  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.

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 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?

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?  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\
>

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

[MON KEY]

On Wed, Jun 16, 2010 at 7:11 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Jun 17, 2010 at 12:02 AM, MON KEY <monkey@sandpframing.com> wrote:
>> 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?

Sorry it took me so long to get back to you on this:

:SEE (URL `http://lispm.dyndns.org/lispm/system-78-48/')
:SEE (URL `http://lispm.dyndns.org/news?ID=NEWS-2010-02-14-1')

Of particular relevance to the topic at hand are the following
procedures from the file: system-78-48/zwei/zmacs.lisp

,----
| ;;; Return T if the buffer has been changed since the last time it
| ;;; was read or written.  If it never has been read or written,
| ;;; ERROR.
| (DEFUN BUFFER-MUNGED-P (BUFFER &OPTIONAL SPECIAL-TOO)
|   (AND (SYMBOLP (BUFFER-FILE-ID BUFFER))
|    (FERROR NIL
|     "BUFFER-MUNGED-P on a file that has not been read or written."))
|   (AND (OR SPECIAL-TOO (NLISTP (BUFFER-FILE-ID BUFFER))
| 	   (NEQ (CAR (BUFFER-FILE-ID BUFFER)) ':SPECIAL-BUFFER))
|        (NEQ (NODE-TICK BUFFER) ':READ-ONLY)
|        (> (NODE-TICK BUFFER) (BUFFER-TICK BUFFER))))
|
| ;;; Return T is a buffer should be offered for saving.  If it has
| ;;; been touched since it was last read or created (if it was a (New
| ;;; File)).
| (DEFUN BUFFER-NEEDS-SAVING-P (BUFFER &OPTIONAL SPECIAL-TOO)
|   (AND (BUFFER-FILE-ID BUFFER)
|        (OR SPECIAL-TOO (NLISTP (BUFFER-FILE-ID BUFFER))
| 	   (NEQ (CAR (BUFFER-FILE-ID BUFFER)) ':SPECIAL-BUFFER))
|        (NEQ (NODE-TICK BUFFER) ':READ-ONLY)
|        (> (NODE-TICK BUFFER) (BUFFER-TICK BUFFER))))
|
| ;;; Update PACKAGE from the current buffer.  This is called whenever
| ;;; either the current buffer changes, or the package of the buffer
| ;;; changes.
| (DEFUN COMPUTE-BUFFER-PACKAGE (BUFFER)
|   (OR *RECURSIVE-PKG-FIND-PACKAGE-KLUDGE*
|       (LET ((GENERIC-PATHNAME (BUFFER-GENERIC-PATHNAME BUFFER))
| 	    (*RECURSIVE-PKG-FIND-PACKAGE-KLUDGE* T)
| 	    N)
| 	(MULTIPLE-VALUE-BIND (VARS VALS)
| 	    (FS:FILE-PROPERTY-BINDINGS GENERIC-PATHNAME)
| 	  (IF (SETQ N (FIND-POSITION-IN-LIST 'PACKAGE VARS))
| 	      (SETQ PACKAGE (NTH N VALS))
| 	      (FUNCALL GENERIC-PATHNAME
| 	      ':PUTPROP (PKG-NAME PACKAGE) 'PACKAGE)))))
| 	        NIL)
`----

:SEE (URL `http://lispm.dyndns.org/lispm/system-78-48/zwei/zmacs.lisp')

It is important that we be clear w/re the difference between
Common-Lisp style packages and Elisp packages.

Whereas the Emacs-lisp package is more akin to the GNU/Linux
distribution concept of a pkg (e.g. sourcecode file(s) that extends
the user's system once installed and/or compiled), the Common-Lisp
packages is more similiar to what you might get if you were to combine
the fully qualified symbols of an XML-namespace w/ the scoping rules
of lexically (compiled/source-based) defined/bound symbols local to a
particular subsystem within a running system where each package has a
fully dedicated symbol table (think obarray) with internal, external,
and inherited symbols.

Once you have packages/namespacing/lexical-scoping you can put your
symbols in a corner where they can no longer come and go as they
please unless they ask nicely.  If you want to make certain features
dynamic you declare them `special' but FTMP the symbols live happily
in their own little world because they are well fed and provided for.

(URL `http://www.lispworks.com/documentation/HyperSpec/Body/11_aa.htm')

Within a given namespace when we want content to be frobbed by or with
a private symbol from the the context of a specific buffer we do so by
either:

 - accessing those symbols direclty by directly accessing them by the
   package they live in e.g.:

   (setf minion::*grovel-var*
     (minion::grovel (minion::frob minion::*grovel-var*)))

 - or by importing the symbol into some package namespace specific to
   a buffer (or type of buffer) and thereafter calling it directly
   with e.g.:

   (use-package 'minion 'minions-cousin)

   (setf *grovel-var* (grovel (frob *grovel-var*)))

IOW many of the control/state related issues that are currently piggy
backed upon Emacs/Elisp concept of the buffer/major-mode could instead
be handled by using the formal set of first class tools the
(Mac/Inter/Spice/Butterfly/Z)Lisp inspired/derived languages like
CLTL-[1-2]/ANSI Lisp's provide(d).

This said, AFAICT the major-mode distinctions made by contemporary
Emacsen (and in particular the `multiple major mode') do not have have
direct correspondence with the features provided with the defunct
historic Lisp systems. This said, it isn't clear that they were needed
given the additional features that the system/language provided. e.g.

 "Why would anyone endeavor to chop down trees with a blunt hammer
  when they have a perfectly good chainsaw?"

Unfortunately I'm too young to know this. Prob. only those fortunate
enough to have had the opportunity to actively use such lisp systems
can answer this question with any authority. Certainly there is at
least one Emacs here who did/can :)

--
/s_P\

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

[Stefan Monnier]

>> No.  If buffer-offer-save is bound to a major-mode, then it should not
>> be permanent-local (i.e. if that variable is permanent-local, then the
>> major-mode will need to use change-major-mode-hook to kill that var
>> explicitly).
> So, the burden is shifted from major-mode authors and users to check/test for
> the property where the check has not otherwise been explicitly required of
> either in the past?

I have no idea what "check/test" you're referring to.

>> AFAICT, all current uses of buffer-offer-save in Emacs are in places
>> where the major-mode is not expected to change and where, in case it
>> does change, it doesn't matter much what happens anyway.
> So, is it fair to assume that for these major-mode's which are not
> expected to change there is no particular benefit/gain of having
> buffer-offer-save permanent-local?

Yes.

>> The exchange explains how making kill-buffer-hook permanent-local is not
>> too terrible, because specific major-modes can override the permanence
>> via change-major-mode-hook.  That same argument applies to any variable,
>> including buffer-offer-save.
> Maybe, but they don't necessarily apply in the same way though b/c:
>  - buffer-offer-save is a boolean**;

Why would that matter?

>  - buffer-offer-save is a buffer-local whereas kill-buffer-hook is a
>    kind of "buffer-global";

The permanent-local property only matters when the variable is
buffer-local, so the fact that buffer-offer-save is always buffer-local
whereas kill-buffer-hook is only sometimes so is irrelevant.

> In this thread below RMS establishes a clear recipe for how he
> suggest to address exactly this sort of issue:

This is unrelated to buffer-offer-save.


        Stefan

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

[Kevin Rodgers]

Stefan Monnier wrote:
> And while a permanent-local variable can easily be made non-permanent
> via change-major-mode-hook, it is a lot more difficult to reliably make
> a non-permanent-local variable permanent.

Isn't it as easy as:

(put 'nonpermanent-local-variable 'permanent-local t)

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Stefan Monnier]

>> And while a permanent-local variable can easily be made non-permanent
>> via change-major-mode-hook, it is a lot more difficult to reliably make
>> a non-permanent-local variable permanent.

> Isn't it as easy as:
> (put 'nonpermanent-local-variable 'permanent-local t)

No, I mean without making it a permanent-local variable.
I.e. it's easy to reliably "emulate" the effect of permanent-local=nil
whereas it's difficult to do emulate permanent-local=t


        Stefan

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

[MON KEY]

Kevin Rodgers wrote:
> Isn't it as easy as:
>
> (put 'nonpermanent-local-variable 'permanent-local t)

Yep, and therein lies the rub.

My major-mode did this instead:

(put 'deadweight-unless-you-look-for-me 'permanent-local t)

How does _your_ major-mode know to test for this permanent local?

And vice versa, how does _my_ major-mode know to test for
`nonpermanent-local-variable'?

Right now we rely on the scorched earth tactics of
`kill-all-local-variables' to resolve these sorts of ambiguities. IOW
we napalm the room to erase whatever farts the previous fella left
behind.  And, in general this approach has been a fairly effective
form of air freshener but doesn't cover up certain lingering odors:

,----
| As a special exception, local variables whose names have a non-nil
| `permanent-local' property are not eliminated by this function.
|
`---- (describe-function 'kill-all-local-variables)


If you find the existing approach above ugly then you may then agree
with the proposed solution to:

 a) elevate some symbol e.g. `buffer-offer-save' to a higher status

 b) teach your major-mode to check for this symbol (where applicable)

 c) hope everyone elses major-modes do this as well

 d) wait for Emacs to begin verbosely prompting you to save every last
    useless buffer you visited _before_ she will allow her process to
    terminate.

 e) Seek out the offending elisp code that did:

    (set (make-local-variable 'buffer-offer-save) t)

    i) Check in a coupla places 'cause the major-mode/code which first
        set the var may be two or three times removed.

 f) Having located the offending code fire off a disgruntled email to
    the responsible party asking why they thought it reasonable to
    reach into your Emacsen and toggle that variable in _your_ buffers
    without first asking if it was kosher to do so...

 g) Become increasingly baffled when said coder explains that while the
    property _was_ set by his code _you_ are wrong to be miffed b/c he
    assumed:

    "this is what most people expect.
     You are the corner case.
     Sorry 'bout that"

Good luck trying to explain to someone how it is that the real
exceptional special circumstance isn't your expectations but the
permanent local variable that keeps getting flipped behind your back
when you aren't looking.

--
/s_P\

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

[Lennart Borgman]

On Thu, Jun 17, 2010 at 11:36 PM, MON KEY <monkey@sandpframing.com> wrote:
> Kevin Rodgers wrote:
>> Isn't it as easy as:
>>
>> (put 'nonpermanent-local-variable 'permanent-local t)
>
> Yep, and therein lies the rub.
>
> My major-mode did this instead:
>
> (put 'deadweight-unless-you-look-for-me 'permanent-local t)


Is not this just a misuse of a feature? You can misuse any feature.

Your major mode is simply not expected to to this kind of things. It
is not expected to do a lot of other things either.

And this has nothing to do with the change I proposed.

Instead, as I said before (a bit less explicit) it rather has to do
with complexity.


> How does _your_ major-mode know to test for this permanent local?
>
> And vice versa, how does _my_ major-mode know to test for
> `nonpermanent-local-variable'?
>
> Right now we rely on the scorched earth tactics of
> `kill-all-local-variables' to resolve these sorts of ambiguities. IOW
> we napalm the room to erase whatever farts the previous fella left
> behind.  And, in general this approach has been a fairly effective
> form of air freshener but doesn't cover up certain lingering odors:
>
> ,----
> | As a special exception, local variables whose names have a non-nil
> | `permanent-local' property are not eliminated by this function.
> |
> `---- (describe-function 'kill-all-local-variables)
>
>
> If you find the existing approach above ugly then you may then agree
> with the proposed solution to:
>
>  a) elevate some symbol e.g. `buffer-offer-save' to a higher status
>
>  b) teach your major-mode to check for this symbol (where applicable)
>
>  c) hope everyone elses major-modes do this as well
>
>  d) wait for Emacs to begin verbosely prompting you to save every last
>    useless buffer you visited _before_ she will allow her process to
>    terminate.
>
>  e) Seek out the offending elisp code that did:
>
>    (set (make-local-variable 'buffer-offer-save) t)
>
>    i) Check in a coupla places 'cause the major-mode/code which first
>        set the var may be two or three times removed.
>
>  f) Having located the offending code fire off a disgruntled email to
>    the responsible party asking why they thought it reasonable to
>    reach into your Emacsen and toggle that variable in _your_ buffers
>    without first asking if it was kosher to do so...
>
>  g) Become increasingly baffled when said coder explains that while the
>    property _was_ set by his code _you_ are wrong to be miffed b/c he
>    assumed:
>
>    "this is what most people expect.
>     You are the corner case.
>     Sorry 'bout that"
>
> Good luck trying to explain to someone how it is that the real
> exceptional special circumstance isn't your expectations but the
> permanent local variable that keeps getting flipped behind your back
> when you aren't looking.
>
> --
> /s_P\
>
>

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

[MON KEY]

On Thu, Jun 17, 2010 at 6:25 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> Is not this just a misuse of a feature? You can misuse any feature.
>

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).

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.

> And this has nothing to do with the change I proposed.

It most certainly does.

Kevin's query illustrates that where persisting state in a buffer is
merely a matter of putting some permanent property on the buffer this
is trivially accomplished. Its not at all unlike a web-browser setting
a session cookie to hold state (and approximately as unclean).

> 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.

Someone might just as well ask why not use a delimited continuation or
closure based protocol to hold these kinds of state instead if its
such a complex situation? Alas, you can't stop a cookie monster :)

> Your major mode is simply not expected to to this kind of things.

This is exactly my point. They will do it.  And your proposal is to
have this behaviour explicitly blessed.

>
> And this has nothing to do with the change I proposed.
>
Why not?

Couldn't you accomplish a major-moded state change by doing something
like this:

(put 'dead-weight-unless-you-look-for-me 'permanent-local t)

(with-current-buffer (current-buffer)
  (set (make-local-variable 'dead-weight-unless-you-look-for-me) t))

;; (unintern 'dead-weight-unless-you-look-for-me)
(setplist 'dead-weight-unless-you-look-for-me
          `(,(get-buffer (current-buffer))
            (:buffer-offer-save t)))

(with-current-buffer (get-buffer (other-buffer))
  (buffer-local-value
   (intern-soft "dead-weight-unless-you-look-for-me")
   (current-buffer)))
;; => void over there

(buffer-local-value
 (intern-soft "dead-weight-unless-you-look-for-me")
 (current-buffer))
;; => t over here

(get
 (intern-soft "dead-weight-unless-you-look-for-me")
 (get-buffer (current-buffer)))
;; => (:buffer-offer-save t)

(get (intern-soft "dead-weight-unless-you-look-for-me")
     (get-buffer (current-buffer)))
;=> (:buffer-offer-save t)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
 (get-buffer (current-buffer)))
 	     :buffer-offer-save)
;=> (:buffer-offer-save t)

(fundamental-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
; => t

(emacs-lisp-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
;=> t

(fundamental-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
;=> t

(with-current-buffer (get-buffer (other-buffer))
  (buffer-local-value
   (intern-soft "dead-weight-unless-you-look-for-me")
   (current-buffer)))
;=> still void.

--
/s_P\

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

[Lennart Borgman]

On Fri, Jun 18, 2010 at 2:13 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Thu, Jun 17, 2010 at 6:25 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>>
>> Is not this just a misuse of a feature? You can misuse any feature.
>>
>
> 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. But this is a developing environment. There
are lot of things in Emacs you can use but you should not use unless
you know what you are doing.

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.

It is beyond me why you are suggesting something like that.


>> And this has nothing to do with the change I proposed.
>
> It most certainly does.
>
> Kevin's query illustrates that where persisting state in a buffer is
> merely a matter of putting some permanent property on the buffer this
> is trivially accomplished.


Sorry, I can see nothing here that has anything to do with my proposal.


>> 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. Why? To me it just looks like you are
overlooking the complexity of the question.

Sure there are cases like where your answer what be sensible. But that
does not mean it is it here.


>> Your major mode is simply not expected to to this kind of things.
>
> This is exactly my point. They will do it.  And your proposal is to
> have this behaviour explicitly blessed.


Then just don't use libraries from authors that do not know what they are doing.


>> 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.

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. What are you trying to prove?


> (put 'dead-weight-unless-you-look-for-me 'permanent-local t)
>
> (with-current-buffer (current-buffer)
>  (set (make-local-variable 'dead-weight-unless-you-look-for-me) t))
>
> ;; (unintern 'dead-weight-unless-you-look-for-me)
> (setplist 'dead-weight-unless-you-look-for-me
>          `(,(get-buffer (current-buffer))
>            (:buffer-offer-save t)))
>
> (with-current-buffer (get-buffer (other-buffer))
>  (buffer-local-value
>   (intern-soft "dead-weight-unless-you-look-for-me")
>   (current-buffer)))
> ;; => void over there
>
> (buffer-local-value
>  (intern-soft "dead-weight-unless-you-look-for-me")
>  (current-buffer))
> ;; => t over here
>
> (get
>  (intern-soft "dead-weight-unless-you-look-for-me")
>  (get-buffer (current-buffer)))
> ;; => (:buffer-offer-save t)
>
> (get (intern-soft "dead-weight-unless-you-look-for-me")
>     (get-buffer (current-buffer)))
> ;=> (:buffer-offer-save t)
>
> (plist-get
>  (get (intern-soft "dead-weight-unless-you-look-for-me")
>  (get-buffer (current-buffer)))
>             :buffer-offer-save)
> ;=> (:buffer-offer-save t)
>
> (fundamental-mode)
>
> (plist-get
>  (get (intern-soft "dead-weight-unless-you-look-for-me")
>      (get-buffer (current-buffer)))
>  :buffer-offer-save)
> ; => t
>
> (emacs-lisp-mode)
>
> (plist-get
>  (get (intern-soft "dead-weight-unless-you-look-for-me")
>      (get-buffer (current-buffer)))
>  :buffer-offer-save)
> ;=> t
>
> (fundamental-mode)
>
> (plist-get
>  (get (intern-soft "dead-weight-unless-you-look-for-me")
>      (get-buffer (current-buffer)))
>  :buffer-offer-save)
> ;=> t
>
> (with-current-buffer (get-buffer (other-buffer))
>  (buffer-local-value
>   (intern-soft "dead-weight-unless-you-look-for-me")
>   (current-buffer)))
> ;=> still void.
>
> --
> /s_P\
>

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

[MON KEY]

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\

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

[Lennart Borgman]

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\
>

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

[MON KEY]

On Sat, Jun 19, 2010 at 11:20 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> 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.

Yes, I'm sure there are. This is to be expected given that the outcome
they are attempting to accomplish is untenable with Emacs' current
limitations. I wish you the best of luck in your ongoing endeavors to
struggle with this. I can assure you though that I certainly won't be
extending my efforts towards pushing that rock up any hills.

> 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.

I wasn't aware that nxml's parser is broken.
Has anyone informed James Clark?

Why should nxml-mode need to do such a thing?

Isn't this like asking one to construct a lisp interpreter capable of
parsing non-well-formed S-expressions?

Besides, what does nxml's parser have to do with buffer-offer-save
being made permanent local?

--
/s_P\