bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Jorgen Schaefer]

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@linux-m68k.org-20130126151309-wk3nb8t4xitw94lh
Configured using:
 `configure --without-x --with-x-toolkit=no'

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Glenn Morris]

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

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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Stefan Monnier]

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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-08-23 03:21:26] wrote:
> Stefan Monnier <monnier@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@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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Lars Ingebrigtsen]

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

> FWIW, this bug was presumably fixed with:
>
>     commit a104f656c8217b027866d32e8d7bf024a671e3cc
>     Author: Stefan Monnier <monnier@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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar

[Eli Zaretskii]

> Cc: 13814@debbugs.gnu.org, Jorgen Schaefer <forcer@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@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.