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 02:33:58 +0200	[thread overview]
Message-ID: <AANLkTil6xc3mJDKPutAz9pPYE76Y-1Wq1vwZNU9CN4rR@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilWIQaPfosKEpPr09fg4DnEwG9sxKB5Ac9dA1UX@mail.gmail.com>

On Fri, Jun 18, 2010 at 2:13 AM, MON KEY <monkey@sandpframing.com> wrote:
> 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).


For an OS I would agree. But this is a developing environment. There
are lot of things in Emacs you can use but you should not use unless
you know what you are doing.

So there is nothing special with permanent-local in this regard.


> 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.


It would not work. You would just add another non-backward complexity.

It is beyond me why you are suggesting something like that.


>> 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.


Sorry, I can see nothing here that has anything to do with my proposal.


>> 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.


You seem to be sure of that. Why? To me it just looks like you are
overlooking the complexity of the question.

Sure there are cases like where your answer what be sensible. But that
does not mean it is it here.


>> 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.


Then just don't use libraries from authors that do not know what they are doing.


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


There is nothing in the change I propose that makes the behavior or
possibility of other developers different.

If you think differently it suggest to me you have misunderstood the situation.


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


Yes. So what. What are you trying to prove?


> (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:33 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
2010-06-18  0:33     ` Lennart Borgman [this message]
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=AANLkTil6xc3mJDKPutAz9pPYE76Y-1Wq1vwZNU9CN4rR@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).