unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: kevin.d.rodgers@gmail.com
Cc: emacs-devel@gnu.org
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Thu, 17 Jun 2010 17:36:57 -0400	[thread overview]
Message-ID: <AANLkTilPFgD4m1T2uJEh2Y9RQfFQiWf4Y9G2ZULUKm3C@mail.gmail.com> (raw)

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)

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	other threads:[~2010-06-17 21:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 21:36 MON KEY [this message]
2010-06-17 22:25 ` Proposal: `buffer-offer-save' be made a permanent-local Lennart Borgman
2010-06-18  0:13   ` MON KEY
2010-06-18  0:33     ` Lennart Borgman
2010-06-18  2:53       ` MON KEY
2010-06-19 15:20         ` Lennart Borgman
2010-06-20  5:05           ` MON KEY
  -- strict thread matches above, loose matches on Subject: below --
2010-06-14  0:17 MON KEY
2010-06-14  0:59 ` Lennart Borgman
2010-06-14  1:00 ` Stefan Monnier
2010-06-14  8:48   ` MON KEY
2010-06-14  9:18     ` Lennart Borgman
2010-06-16  7:21       ` MON KEY
2010-06-16 11:39         ` Lennart Borgman
2010-06-16 22:02           ` MON KEY
2010-06-16 23:11             ` Lennart Borgman
2010-06-28  4:39               ` MON KEY
2010-06-14 13:38     ` Stefan Monnier
2010-06-17  4:15   ` Kevin Rodgers
2010-06-17 20:19     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTilPFgD4m1T2uJEh2Y9RQfFQiWf4Y9G2ZULUKm3C@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    --cc=kevin.d.rodgers@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).