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: 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 03:21:41 -0400	[thread overview]
Message-ID: <AANLkTikX68URkQho4oqyAtv42O1u7TIuTsp9Ago2GA4Y@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilnXROAvc6lBymV7wgaIWkRJPvt-1GGwc6XDCWQ@mail.gmail.com>

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

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.

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.

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.

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

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

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
(which BTW is why I believe some concern over this is justified). Are
the rules for variable buffer locality arbitrary? Where is the
documentation for proper/idiomatic use of permanent-local variable.  I
ask this because I'm unable to find a reference to the
`permanent-local-hook' though it _does_ exist.

What should others understand about the proposed change?

What specific problems does it solve?

What happens if the proposed change is not implemented.

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

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

--
/s_P\



  reply	other threads:[~2010-06-16  7:21 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 [this message]
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
  -- 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

  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=AANLkTikX68URkQho4oqyAtv42O1u7TIuTsp9Ago2GA4Y@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.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 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).