From: Michael Heerdegen <michael_heerdegen@web.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Joost Kremers <joostkremers@fastmail.fm>, 40088@debbugs.gnu.org
Subject: bug#40088: 27.0.90; Symbol’s value as variable is void: debugger-outer-match-data
Date: Wed, 18 Mar 2020 01:06:32 +0100 [thread overview]
Message-ID: <8736a6edbr.fsf@web.de> (raw)
In-Reply-To: <c13efee8-cba1-de75-b304-c1ab95eea04e@yandex.ru> (Dmitry Gutov's message of "Tue, 17 Mar 2020 13:06:09 +0200")
Dmitry Gutov <dgutov@yandex.ru> writes:
> It doesn't look like this bug should be solved this way. Having
> "... is unbound" is better because it points at some function
> forgetting to let-bind this variable (someone should find out which
> and to which values).
>
> Whereas if it had an init value, that would mask such problems because
> nil is a somewhat valid value.
If there are lots of cases like this under the cited thousands then I
guess we need a way to declare a variable special without assigning an
init value.
I don't like the (defvar var) syntax we have now. It's different than
the (defvar var value) syntax in more than one way, and it's too
easily overseeable that it doesn't make a variable special.
Michael.
next prev parent reply other threads:[~2020-03-18 0:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 11:40 bug#40088: 27.0.90; Symbol’s value as variable is void: debugger-outer-match-data Joost Kremers
2020-03-17 1:01 ` Michael Heerdegen
2020-03-17 10:41 ` Robert Pluim
2020-03-17 11:06 ` Dmitry Gutov
2020-03-18 0:06 ` Michael Heerdegen [this message]
2020-03-18 0:12 ` bug#40088: 27.0.90; Symbol?s " Drew Adams
2020-03-18 1:44 ` Noam Postavsky
2020-03-18 1:49 ` Drew Adams
2020-03-18 22:31 ` Michael Heerdegen
2020-03-18 6:34 ` bug#40088: 27.0.90; Symbol’s " Dmitry Gutov
2020-03-18 22:24 ` Michael Heerdegen
2020-03-18 22:30 ` Dmitry Gutov
2020-03-18 22:46 ` Michael Heerdegen
2020-03-17 11:44 ` Noam Postavsky
2020-03-19 0:04 ` Noam Postavsky
2020-03-19 0:18 ` Stefan Monnier
2020-03-20 8:37 ` Noam Postavsky
2020-03-20 8:56 ` Eli Zaretskii
2020-03-21 23:47 ` Noam Postavsky
2020-03-22 14:25 ` Eli Zaretskii
2020-03-23 3:17 ` Noam Postavsky
2020-03-23 3:30 ` Eli Zaretskii
2020-03-23 3:40 ` Noam Postavsky
2020-03-23 14:16 ` Eli Zaretskii
2020-03-23 14:34 ` Noam Postavsky
2020-03-23 15:53 ` Joost Kremers
2020-03-20 13:20 ` Stefan Monnier
2020-03-20 14:00 ` Robert Pluim
2020-03-20 14:51 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736a6edbr.fsf@web.de \
--to=michael_heerdegen@web.de \
--cc=40088@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=joostkremers@fastmail.fm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).