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

On Thu, Jun 17, 2010 at 6:25 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> Is not this just a misuse of a feature? You can misuse any feature.
>

NO! If the elisp API exposes permanent-local it isn't a misuse it is
to be expected that people will use it (whether you or I agree with
such use or not).

The `misuse' of permanent-local is the ad hoc elevation of only _some_
symbols to permanent local status.

Let all symbols be permanent permanent local by default or stop adding
them arbitrarily to satisfy a kludge.

> And this has nothing to do with the change I proposed.

It most certainly does.

Kevin's query illustrates that where persisting state in a buffer is
merely a matter of putting some permanent property on the buffer this
is trivially accomplished. Its not at all unlike a web-browser setting
a session cookie to hold state (and approximately as unclean).

> Instead, as I said before (a bit less explicit) it rather has to do
> with complexity.

Nonsense, the complexity is an outcome of a series of simplistic
solution being thrown at the problem.

Someone might just as well ask why not use a delimited continuation or
closure based protocol to hold these kinds of state instead if its
such a complex situation? Alas, you can't stop a cookie monster :)

> Your major mode is simply not expected to to this kind of things.

This is exactly my point. They will do it.  And your proposal is to
have this behaviour explicitly blessed.

>
> And this has nothing to do with the change I proposed.
>
Why not?

Couldn't you accomplish a major-moded state change by doing something
like this:

(put 'dead-weight-unless-you-look-for-me 'permanent-local t)

(with-current-buffer (current-buffer)
  (set (make-local-variable 'dead-weight-unless-you-look-for-me) t))

;; (unintern 'dead-weight-unless-you-look-for-me)
(setplist 'dead-weight-unless-you-look-for-me
          `(,(get-buffer (current-buffer))
            (:buffer-offer-save t)))

(with-current-buffer (get-buffer (other-buffer))
  (buffer-local-value
   (intern-soft "dead-weight-unless-you-look-for-me")
   (current-buffer)))
;; => void over there

(buffer-local-value
 (intern-soft "dead-weight-unless-you-look-for-me")
 (current-buffer))
;; => t over here

(get
 (intern-soft "dead-weight-unless-you-look-for-me")
 (get-buffer (current-buffer)))
;; => (:buffer-offer-save t)

(get (intern-soft "dead-weight-unless-you-look-for-me")
     (get-buffer (current-buffer)))
;=> (:buffer-offer-save t)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
 (get-buffer (current-buffer)))
 	     :buffer-offer-save)
;=> (:buffer-offer-save t)

(fundamental-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
; => t

(emacs-lisp-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
;=> t

(fundamental-mode)

(plist-get
 (get (intern-soft "dead-weight-unless-you-look-for-me")
      (get-buffer (current-buffer)))
 :buffer-offer-save)
;=> t

(with-current-buffer (get-buffer (other-buffer))
  (buffer-local-value
   (intern-soft "dead-weight-unless-you-look-for-me")
   (current-buffer)))
;=> still void.

--
/s_P\



  reply	other threads:[~2010-06-18  0:13 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
2010-06-18  0:13   ` MON KEY [this message]
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=AANLkTilWIQaPfosKEpPr09fg4DnEwG9sxKB5Ac9dA1UX@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    --cc=kevin.d.rodgers@gmail.com \
    --cc=lennart.borgman@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).