Re: void variable

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Of course, `defcustom' has exactly the same problem as `defvar'.  So
> doing this for defvar and not defcustom seems inconsistent.  Strictly

Indeed.  We had already mentioned defcustom, but I'd forgotten about it.
But now that I looked at it, I also see that it's a bit ugly to do
(ideally, defcustom would use defvar internally, but given the way
custom is supposed to work, it's not easy to do).  We'd probably need to
create a new function like `outer-default-boundp' just for that.

> speaking, `defconst' also has the same problem, but let-binding a
> variable defined with defconst seems very iffy in any circumstances.

The situation for defconst is a bit different indeed.
The byte-compiler already warns when we do

   (defconst toto 1)
   (let ((toto 2)) (balbla))

It doesn't do that if the defconst was in another file, tho (because after
the defconst is executed Emacs does not remember whether it was a defconst
or a defvar or a setq).  We could easily add a bit in the symbol to keep
track of which vars are "const" to work around this (my own local Emacs
branch has had that for a while, even making all `defconst'd variables
read-only).

> The message:  VAR is still globally unbound
> looks cryptic.

:-)

> "Can't bind `foo-bar' globally: `let' around `defvar'"
> I would prefer:
> "Warning: defvar for locally bound `%s' failed to globally define it."
[...]
> For one thing, local bindings are not always made with `let'.

I like having `defvar' and `let' in the message.  How about:

   "Warning: defvar ignored because %s is let-bound"

Or maybe "skipped" or "failed" is better than "ignored".

> Anyway, somebody with a reasonably fast machine may only see this when
> studying the *Messages* buffer.  It easily can be overwritten by
> messages like:

Actually I think the problem can show up on a slow machine just as well.
But it's nothing new and is not specific to this particular case.


        Stefan