emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lennart Borgman
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Mon, 14 Jun 2010 11:18:02 +0200

On Mon, Jun 14, 2010 at 10:48 AM, MON KEY <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]