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

[MON KEY]

On Sun, Jun 13, 2010 at 9:00 PM, Stefan Monnier
<address@hidden> 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\