GNU bug report logs - #13814
24.3.50; Dynamic variables shadowing prevent defvar

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13814 in the body.
You can then email your comments to 13814 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Mon, 25 Feb 2013 20:30:29 +0100

When a file is autoloaded, defvar will fail to define locally-set,
dynamic variabls, resulting in such variables not being defined at all,
even after their local binding ends.

Situation:

(let ((some-var-that-influences-behavior t))
  (some-function-that-autoloads-a-library))

If the library which is autoloaded by
`some-function-that-autoloads-a-library' defines
`some-var-that-influences-behavior' using defvar or defcustom, the
variable is never bound globally because defvar thinks it's already
defined.

I would expect defvar to notice that the variable is bound only
locally/temporarily and define a global binding anyhow.

Reproduction:

Put this file, bug-lib.el, somewhere in `load-path':

-----8<----- bug-lib.el -----8<----- 

(defvar bug-variable t
  "This variable is not defined when autoloaded.")

(defun bug-variable-value ()
  bug-variable)

----->8----- ---------- ----->8-----

Then execute the following lines:

(autoload 'bug-variable-value "bug-lib.el")

(let ((bug-variable nil))
  (bug-variable-value))

=> nil

(bug-variable-value)

=> Error, `bug-variable' is not defined.


Regards,
        -- Jorgen


In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu)
Bzr revision: 111608 schwab <at> linux-m68k.org-20130126151309-wk3nb8t4xitw94lh
Configured using:
 `configure --without-x --with-x-toolkit=no'

Message #8 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 13814 <at> debbugs.gnu.org
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Mon, 25 Feb 2013 18:15:20 -0500

Yes, it's a long-standing problem. Eg

http://lists.gnu.org/archive/html/emacs-devel/2004-07/msg00589.html

Message #11 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 13814 <at> debbugs.gnu.org
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Mon, 25 Feb 2013 19:03:05 -0500

Thanks for filing it, so we have a clear bug-number for this long
standing problem.  If someone wants to take a crack at fixing it,
I think that we should add a `set-toplevel-default' which defvar and
defcustom could use, as for how to implement it, I you can take a look
at the check&warning in the C code of `defvar'.


        Stefan

Message #16 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Mon, 23 Aug 2021 03:21:26 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Thanks for filing it, so we have a clear bug-number for this long
> standing problem.  If someone wants to take a crack at fixing it,
> I think that we should add a `set-toplevel-default' which defvar and
> defcustom could use, as for how to implement it, I you can take a look
> at the check&warning in the C code of `defvar'.

When running this from M-: now, I get the following backtrace:

Debugger entered--Lisp error: (error "Defining as dynamic an already lexical var")
  (defvar bug-variable t "This variable is not defined when autoloaded.")
  eval-buffer(#<buffer  *load*> nil "/tmp/bug-lib.el" nil t)  ; Reading at buffer position 74
  load-with-code-conversion("/tmp/bug-lib.el" "/tmp/bug-lib.el" nil t)
  (bug-variable-value)
  (let ((bug-variable nil)) (bug-variable-value))
  eval((let ((bug-variable nil)) (bug-variable-value)) t)
  eval-expression((let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
  funcall-interactively(eval-expression (let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
  call-interactively(eval-expression nil nil)

So this signals an error when doing the

(let ((bug-variable nil))
  (bug-variable-value))

from a lexical context.

And...  from a dynamic context, it seems like this works as it should
now?  That is, the defvar "punches through" the let binding and defines
the variable properly.  (Which I didn't know; last time I looked at
this, it didn't work, but it's some years back.)

Has this been fixed, or am I testing it wrong somehow?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #21 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Tue, 24 Aug 2021 17:25:33 -0400

Lars Ingebrigtsen [2021-08-23 03:21:26] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Thanks for filing it, so we have a clear bug-number for this long
>> standing problem.  If someone wants to take a crack at fixing it,
>> I think that we should add a `set-toplevel-default' which defvar and
>> defcustom could use, as for how to implement it, I you can take a look
>> at the check&warning in the C code of `defvar'.

FWIW, this bug was presumably fixed with:

    commit a104f656c8217b027866d32e8d7bf024a671e3cc
    Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
    Date:   Fri Aug 2 17:16:33 2013 -0400

So we should probably close it.

> When running this from M-: now, I get the following backtrace:
>
> Debugger entered--Lisp error: (error "Defining as dynamic an already lexical var")
>   (defvar bug-variable t "This variable is not defined when autoloaded.")
>   eval-buffer(#<buffer  *load*> nil "/tmp/bug-lib.el" nil t)  ; Reading at buffer position 74
>   load-with-code-conversion("/tmp/bug-lib.el" "/tmp/bug-lib.el" nil t)
>   (bug-variable-value)
>   (let ((bug-variable nil)) (bug-variable-value))
>   eval((let ((bug-variable nil)) (bug-variable-value)) t)
>   eval-expression((let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
>   funcall-interactively(eval-expression (let ((bug-variable nil)) (bug-variable-value)) nil nil 127)
>   call-interactively(eval-expression nil nil)
>
> So this signals an error when doing the
>
> (let ((bug-variable nil))
>   (bug-variable-value))
>
> from a lexical context.

Yes, this is a new feature: when we get to the `defvar` the problem is
not just that we need to "punch through" and define the toplevel/dynamic
value of `bug-variable` but also that the `let` would need to be
retroactively changed to be dynamic, which would in general require
time-travel, hence the error.

The fix is to use another var name (if you do want your `let` to be
statically scoped) or to use `dlet`, or an explicit `defvar`, or an
explicit `(require 'bug-lib)`, ...


        Stefan

Message #24 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Wed, 25 Aug 2021 13:00:37 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> FWIW, this bug was presumably fixed with:
>
>     commit a104f656c8217b027866d32e8d7bf024a671e3cc
>     Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
>     Date:   Fri Aug 2 17:16:33 2013 -0400
>
> So we should probably close it.

Yup; closing it now.

> Yes, this is a new feature: when we get to the `defvar` the problem is
> not just that we need to "punch through" and define the toplevel/dynamic
> value of `bug-variable` but also that the `let` would need to be
> retroactively changed to be dynamic, which would in general require
> time-travel, hence the error.

That's being defeatist -- surely theory implies that time travel should
be available any day now...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #29 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Wed, 25 Aug 2021 10:41:09 -0400

> That's being defeatist -- surely theory implies that time travel should
> be available any day now...

I heard it was available in early versions of Emacs,


        Stefan

Message #32 received at 13814 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13814 <at> debbugs.gnu.org, larsi <at> gnus.org, forcer <at> forcix.cx
Subject: Re: bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
Date: Wed, 25 Aug 2021 19:03:31 +0300

> Cc: 13814 <at> debbugs.gnu.org, Jorgen Schaefer <forcer <at> forcix.cx>
> Date: Wed, 25 Aug 2021 10:41:09 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > That's being defeatist -- surely theory implies that time travel should
> > be available any day now...
> 
> I heard it was available in early versions of Emacs,

Emacs supports that since eons ago: see Antinews in the manual.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.