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: Stefan Monnier
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Sun, 13 Jun 2010 21:00:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> 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



reply via email to

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