[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible defvar bug
From: |
Alan Mackenzie |
Subject: |
Re: Possible defvar bug |
Date: |
Mon, 18 Feb 2013 15:09:54 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Feb 18, 2013 at 04:00:28PM +0100, Didier Verna wrote:
> Jambunathan K <address@hidden> wrote:
> > I am certain I don't understand what these paragraphs mean,
> > particularly the second one.
> > lands.
> > ,---- C-h f
> > | If SYMBOL has a local binding, then this form affects the local
> > | binding. This is usually not what you want. Thus, if you need to
> > | load a file defining variables, with this form or with `defconst' or
> > | `defcustom', you should always load that file _outside_ any bindings
> > | for these variables. (`defconst' and `defcustom' behave similarly in
> > | this respect.)
> > `----
> This means that:
> ELISP> (let ((foo 3))
> (defvar foo 1)
> (print foo))
> 3
> ELISP> foo
> *** Eval error *** Symbol's value as variable is void: foo
> ELISP>
> And, no, this is almost never what you want :-) Just like Tassilo
> noticed by accident.
Why would anybody want to defvar a variable inside a let binding which
also defines it, anyway? It may not be totally invalid, but it's
certainly in breach of good taste. I would argue that the current
behaviour _is_ what is wanted, since it alerts one to a probable error.
--
Alan Mackenzie (Nuremberg, Germany).
Re: Possible defvar bug, Glenn Morris, 2013/02/18