GNU bug report logs - #64543
[PATCH] package-report-bug: don't fail on custom groups defined by eval

Previous Next

Full log

Message #29 received at 64543 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 64543 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#64543: [PATCH] package-report-bug: don't fail on custom
 groups defined by eval
Date: Sat, 15 Jul 2023 07:40:01 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: sbaugh <at> catern.com,  64543 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
>> Date: Fri, 14 Jul 2023 19:44:15 +0000
>> 
>> 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.

>                     The entire discussion of this bug never described
> such a case, AFAICT.  (Also, the commit log message could use some
> loving care: what does it mean when it says "Previously"?)

How about

--8<---------------cut here---------------start------------->8---
* lisp/emacs-lisp/package.el (package-report-bug): Do not assume that
every entry in 'custom-current-group-alist' has a non-nil entry for a
filename.

It is possible for a group to not be associated with any file, e.g. when
a 'defgroup' form is evaluated using 'eval-expression'.  (bug#64543)
--8<---------------cut here---------------end--------------->8---

A related discussion might be if `custom-declare-group' could be
improved, by not just consulting `load-file-name', but using
`macroexp-file-name'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.