From: Eli Zaretskii <eliz@gnu.org>
To: Philip Kaludercic <philipk@posteo.net>
Cc: sbaugh@janestreet.com, 64543@debbugs.gnu.org, sbaugh@catern.com
Subject: bug#64543: [PATCH] package-report-bug: don't fail on custom groups defined by eval
Date: Sat, 15 Jul 2023 11:57:06 +0300 [thread overview]
Message-ID: <83h6q5d02l.fsf@gnu.org> (raw)
In-Reply-To: <87mszx62su.fsf@posteo.net> (message from Philip Kaludercic on Sat, 15 Jul 2023 07:40:01 +0000)
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64543@debbugs.gnu.org
> Date: Sat, 15 Jul 2023 07:40:01 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Eli, would it be OK to push this to emacs-29, as this is a bug in the
> >> existing code? Most of the changes are indentation/whitespace changes
> >> anyway.
> >
> > I don't understand the cases in which this bug happens, and so cannot
> > make the decision.
>
> Spencer gave this example:
>
> >> Previously we just assumed that the car of an element of
> >> custom-current-group-alist was a filename. But actually it can be nil
> >> if a custom group was defined by just evaling Lisp.
> >
> > Where is this behaviour documented? I couldn't reproduce it with a
> > simple experiment.
>
> To reproduce:
> M-: (defgroup mygroup nil "my group") RET
>
> The patch would ensure that if groups like these are defined (which
> might happen by mistake), then `package-report-bug' will remain robust
> and not fail due to a unrelated issue.
Is this case important enough to make this change so late in the
pretest? Spencer, how did you bump into this situation in Real Life?
next prev parent reply other threads:[~2023-07-15 8:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-09 17:08 bug#64543: [PATCH] package-report-bug: don't fail on custom groups defined by eval sbaugh
2023-07-10 14:13 ` Philip Kaludercic
2023-07-12 19:26 ` sbaugh
2023-07-12 19:48 ` Philip Kaludercic
2023-07-12 19:56 ` Spencer Baugh
2023-07-14 19:44 ` Philip Kaludercic
2023-07-15 5:49 ` Eli Zaretskii
2023-07-15 7:40 ` Philip Kaludercic
2023-07-15 8:57 ` Eli Zaretskii [this message]
2023-07-13 4:54 ` Eli Zaretskii
[not found] <c6bc281e-d6e5-4c5c-8315-157c6b089330@email.android.com>
2023-07-15 9:23 ` Eli Zaretskii
2023-07-15 10:05 ` Philip Kaludercic
2023-07-15 10:23 ` Eli Zaretskii
2023-07-15 23:33 ` Philip Kaludercic
2023-07-15 17:45 ` sbaugh
2023-07-16 12:33 ` Philip Kaludercic
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=83h6q5d02l.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=64543@debbugs.gnu.org \
--cc=philipk@posteo.net \
--cc=sbaugh@catern.com \
--cc=sbaugh@janestreet.com \
/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).