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

Previous Next

Full log

View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: sbaugh <at> catern.com
Cc: 64543 <at> debbugs.gnu.org
Subject: bug#64543: [PATCH] package-report-bug: don't fail on custom groups defined by eval
Date: Wed, 12 Jul 2023 19:48:43 +0000

sbaugh <at> catern.com writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> sbaugh <at> catern.com writes:
>>
>> Thanks,
>>
>>> From: Spencer Baugh <sbaugh <at> catern.com>
>>> Date: Sun, 9 Jul 2023 12:59:50 -0400
>>> Subject: [PATCH] package-report-bug: don't fail on custom groups defined by
>>>  eval
>>>
>>> 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

OK, I misunderstood your point, I assumed we were talking about
`defcustom' declarations that were evaluated outside the context of a
file.

> I don't think it's documented anywhere?  custom-current-group-alist is
> not documented so this wouldn't be either.
>
>>> * lisp/emacs-lisp/package.el (package-report-bug): Don't fail when a
>>> custom group was defined by eval.
>>> ---
>>>  lisp/emacs-lisp/package.el | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
>>> index 3e6acd9b388..f67e99e04b5 100644
>>> --- a/lisp/emacs-lisp/package.el
>>> +++ b/lisp/emacs-lisp/package.el
>>> @@ -4642,6 +4642,7 @@ package-report-bug
>>>                     (boundp (car ent))
>>>                     (not (eq (custom--standard-value (car ent))
>>>                              (default-toplevel-value (car ent))))
>>> +                   (car group)
>>
>> If you are checking for (car group), when do this in the loop instead
>> of wrapping the entire `dolist'?
>
> Good point.  I was just copying the last condition in the and.  Lifted
> them both out of the loop:
>
> From 2873d4c482acfd1ced749d593fd512c408e0a578 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> catern.com>
> Date: Sun, 9 Jul 2023 22:21:03 -0400
> Subject: [PATCH] Support transforming the dirname used by uniquify

Wrong patch?

Previous Next

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