unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: MON KEY <monkey@sandpframing.com>
Cc: kevin.d.rodgers@gmail.com, emacs-devel@gnu.org
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Fri, 18 Jun 2010 00:25:23 +0200	[thread overview]
Message-ID: <AANLkTilvW09yguC6K-wqYTUKSJtWskDJ7MrTF8hW7JJs@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilPFgD4m1T2uJEh2Y9RQfFQiWf4Y9G2ZULUKm3C@mail.gmail.com>

On Thu, Jun 17, 2010 at 11:36 PM, MON KEY <monkey@sandpframing.com> 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	other threads:[~2010-06-17 22:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 21:36 Proposal: `buffer-offer-save' be made a permanent-local MON KEY
2010-06-17 22:25 ` Lennart Borgman [this message]
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=AANLkTilvW09yguC6K-wqYTUKSJtWskDJ7MrTF8hW7JJs@mail.gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=kevin.d.rodgers@gmail.com \
    --cc=monkey@sandpframing.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).