unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
@ 2013-02-25 19:30 Jorgen Schaefer
  2013-02-25 23:15 ` Glenn Morris
  2013-02-26  0:03 ` Stefan Monnier
  0 siblings, 2 replies; 8+ messages in thread
From: Jorgen Schaefer @ 2013-02-25 19:30 UTC (permalink / raw)
  To: 13814

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'





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2013-02-25 19:30 bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar Jorgen Schaefer
@ 2013-02-25 23:15 ` Glenn Morris
  2013-02-26  0:03 ` Stefan Monnier
  1 sibling, 0 replies; 8+ messages in thread
From: Glenn Morris @ 2013-02-25 23:15 UTC (permalink / raw)
  To: Jorgen Schaefer; +Cc: 13814


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

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2013-02-25 19:30 bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar Jorgen Schaefer
  2013-02-25 23:15 ` Glenn Morris
@ 2013-02-26  0:03 ` Stefan Monnier
  2021-08-23  1:21   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2013-02-26  0:03 UTC (permalink / raw)
  To: Jorgen Schaefer; +Cc: 13814

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2013-02-26  0:03 ` Stefan Monnier
@ 2021-08-23  1:21   ` Lars Ingebrigtsen
  2021-08-24 21:25     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-23  1:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 13814, Jorgen Schaefer

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2021-08-23  1:21   ` Lars Ingebrigtsen
@ 2021-08-24 21:25     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-08-25 11:00       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-24 21:25 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 13814, Jorgen Schaefer

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






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2021-08-24 21:25     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-08-25 11:00       ` Lars Ingebrigtsen
  2021-08-25 14:41         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-25 11:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 13814, Jorgen Schaefer

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2021-08-25 11:00       ` Lars Ingebrigtsen
@ 2021-08-25 14:41         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-08-25 16:03           ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-25 14:41 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 13814, Jorgen Schaefer

> 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






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar
  2021-08-25 14:41         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-08-25 16:03           ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2021-08-25 16:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 13814, larsi, forcer

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-08-25 16:03 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-25 19:30 bug#13814: 24.3.50; Dynamic variables shadowing prevent defvar Jorgen Schaefer
2013-02-25 23:15 ` Glenn Morris
2013-02-26  0:03 ` Stefan Monnier
2021-08-23  1:21   ` Lars Ingebrigtsen
2021-08-24 21:25     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-25 11:00       ` Lars Ingebrigtsen
2021-08-25 14:41         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-25 16:03           ` Eli Zaretskii

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