all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: MON KEY <monkey@sandpframing.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Wed, 16 Jun 2010 13:39:37 +0200	[thread overview]
Message-ID: <AANLkTinO91sHCY1EfPQI2tSbV6axp-RPRrPnkIlSzVQq@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikX68URkQho4oqyAtv42O1u7TIuTsp9Ago2GA4Y@mail.gmail.com>

On Wed, Jun 16, 2010 at 9:21 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Mon, Jun 14, 2010 at 5:18 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> discussion we can think of variable scope versus buffers in a
>> hierarchy like this:
>>
>> 1) * global variable values
>> 2) ** buffer local variable that are permanently local
>> 3) *** buffer local variable that are not permantly local
>
> Thanks, but that didn't really help. :-)

That is not too bad since it gets us a step further.

So, can we then perhaps say that this discussion has very little to do
with the proposal I made? This discussion seems to me much more
general.

> I guess I don't understand why this is the distinction being made and
> in this manner.  It seems conflated to further mix up a variable's
> scope with its extent in this way.

I guess what is at the center of the discussion is what is needed for
elisp to support the editing needs versus a "pure" language that is
does not have to do things like that.

Those needs are sometimes hard to understand and the implementation of
them is constantly growing. It is necessarily a pragmatic approach as
I understand it.

> What I thought I knew:
>
> Emacs/Emacs-lisp has variables that are always global.
>
> A variable is an object accessible as symbol instantiated via defvar,
> defconstant, set, setq, fset, etc.
>
> These can be dynamically bound via let, let*,lambda, condition-case
> etc. and have dynamic scope.  How a variable value exists(or doesn't)
> does not affect its scope.

I would say that so far we are in the concepts of a "pure" language.

> Whether a variable is bound as a property of a buffer (e.g. with a
> specific locality/place) it still has a scope which the standard
> operators can access, bind, and void.

Yes. But now we are approaching the pragmatic part of it as I see it.

Buffer local variables is in my opinion a nice way to handle the needs
specific to editing specific buffer. However "scope" now suddenly has
a little bit different meaning and it is a bit problematic
coordinating the buffer locality with the "old" type of scope (i.e.
without buffer locality).

Personally I can't even imagine how to write an editor with Emacs
capabilities without buffer local variables so I think it is a good
thing. But the logic for variable scope is a bit less clear with it.
(So far we have not touched those difficulties, but since you mention
scope I thought it might be good to say this.)

> These conventional behaviours have been made to act exceptionally if a
> variable is both buffer-local and permanent (e.g. by making the
> variable locally buffer immutable).

I think you mean the difference between buffer local variables that
handle major mode things (those are deleted and maybe set to new
values when changing major mode) and those that handle buffer things
(those are not deleted when changing major mode and we call them for
historical reason permanent local in a buffer).

> As Stefan hinted, and as I concurred, I'm not at all adverse/concerned
> with variables being permanent-local it's the selectivity that bothers
> me b/c it guarantees difficulty for others in knowing the if, when, how, why a
> variable is being acted upon (or isn't).

Yes, I have understood that.

> It seems unclean to make some variables permanent local and others not
> esp. as we don't have a specification to help resolve an ambiguity

I think this ambiguity is exactly what I describe above as "major mode
things" versus "buffer things".

And if you say that those things can not always be clearly distinguish
then I agree. (Here we are back at my proposal. The essence of it is
that I think that buffer-offer-save is more a "buffer thing" than a
"major mode thing".)

> (which BTW is why I believe some concern over this is justified). Are
> the rules for variable buffer locality arbitrary?

Not conceptually but it is sometimes in practice difficult to
distinguish "major mode things" from "buffer things" since they are
more coupled in some circumstances.

> Where is the
> documentation for proper/idiomatic use of permanent-local variable.

There can be no such. It is by necessity a pragmatic approach.
Anything else would make things terribly complex in my opinion.

I do not know if others agree, but a description somewhat like the one
I have given above is the closest you can come. (You can go further
into details, of course.)

> What should others understand about the proposed change?
>
> What specific problems does it solve?

Users may loose data (whole buffers actually) if buffer-offer-save is
erased by a major mode change and the user is unaware of this.

> What happens if the proposed change is not implemented.

See above.

> How is it envisioned it shall be implemented in solving those
> problems?

Just make buffer-offer-save permanent buffer local.

> Where is some code to illustrate an idiomatic use-case for the
> proposed change?.

Here:

- User does in some way (setq buffer-offer-save t) in the buffer of concern.
- Later *he does a major mode switch in this buffer.
- Exit Emacs.

Buffer content is now lost.



  reply	other threads:[~2010-06-16 11:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14  0:17 Proposal: `buffer-offer-save' be made a permanent-local 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2010-06-17 21:36 MON KEY
2010-06-17 22:25 ` 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

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

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

  git send-email \
    --in-reply-to=AANLkTinO91sHCY1EfPQI2tSbV6axp-RPRrPnkIlSzVQq@mail.gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monkey@sandpframing.com \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.