[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: Lennart Borgman
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Fri, 18 Jun 2010 00:25:23 +0200

On Thu, Jun 17, 2010 at 11:36 PM, MON KEY <address@hidden> 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\

reply via email to

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