[Top][All Lists]
[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
- Proposal: `buffer-offer-save' be made a permanent-local, MON KEY, 2010/06/13
- Re: Proposal: `buffer-offer-save' be made a permanent-local, Lennart Borgman, 2010/06/13
- Re: Proposal: `buffer-offer-save' be made a permanent-local,
Stefan Monnier <=
- Re: Proposal: `buffer-offer-save' be made a permanent-local, MON KEY, 2010/06/14
- Re: Proposal: `buffer-offer-save' be made a permanent-local, Lennart Borgman, 2010/06/14
- Re: Proposal: `buffer-offer-save' be made a permanent-local, MON KEY, 2010/06/16
- Re: Proposal: `buffer-offer-save' be made a permanent-local, Lennart Borgman, 2010/06/16
- Re: Proposal: `buffer-offer-save' be made a permanent-local, MON KEY, 2010/06/16
- Re: Proposal: `buffer-offer-save' be made a permanent-local, Lennart Borgman, 2010/06/16
- Re: Proposal: `buffer-offer-save' be made a permanent-local, MON KEY, 2010/06/28
- Re: Proposal: `buffer-offer-save' be made a permanent-local, Stefan Monnier, 2010/06/14
Re: Proposal: `buffer-offer-save' be made a permanent-local, Kevin Rodgers, 2010/06/17