GNU bug report logs -
#60027
30.0.50; Suggestions for (info "(elisp) Local Variables")
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 60027 in the body.
You can then email your comments to 60027 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#60027
; Package
emacs
.
(Tue, 13 Dec 2022 03:35:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 13 Dec 2022 03:35:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
two thoughts about (info "(elisp) Local Variables"):
(1) About saying that dynamical binding is the "default":
| The default scoping rule in Emacs Lisp is called “dynamic scoping”,
| which simply states that the current binding at any given point in the
| execution of a program is the most recently-created binding for that
| variable that still exists. For details about dynamic scoping, and an
| alternative scoping rule called “lexical scoping”, *note Variable
| Scoping::.
Likewise (info "(elisp) Variable Scoping"):
| By default, the local bindings that Emacs creates are “dynamic
| bindings”.
I think saying this gets more and more confusing to newbies, now that
nearly all sources are in lexical binding, and *scratch* also is. It's
opt-in so technically is not strictly wrong, but it is confusing
nonetheless.
I suggest to say something like that the default was dynamical binding
for a long time but Emacs is moving towards using lexical binding as
default. People must be prepared that they will see both dialects, and
this will be the case for another 20 or 30 years at least, so it's not
wrong to tell it's an intermediate state.
But lexical binding is also not the exception any more, it is very
present.
(2) I want to suggest that in (info "(elisp) Local Variables") we add
that
(let* (BINDING1 BINDING2 ...) BODY...)
is equivalent to
(let (BINDING1)
(let (BINDING2)
(let ...
BODY...)))
This would help people to understand, offering a different description,
and would also answer a question I often hear in emacs-help: If it is
legal to specify the same symbol multiple times in `let*'. That node
describes shadowing of bindings so this is a good place to address this
question.
Michael.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 14 Dec 2022 15:48:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Wed, 14 Dec 2022 15:48:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 60027-done <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Tue, 13 Dec 2022 04:33:59 +0100
>
> two thoughts about (info "(elisp) Local Variables"):
[...]
Thanks, I made the changes you proposed on the emacs-29 branch, and
I'm therefore closing this bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 12 Jan 2023 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 218 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.