GNU bug report logs - #33428
27.0.50; edebug-print-{length,level} customization types

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 33428 in the body.
You can then email your comments to 33428 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; edebug-print-{length,level} customization types
Date: Mon, 19 Nov 2018 11:32:51 +0100

The doc strings of edebug-print-length and edebug-print-level imply that
nil is a valid value and indeed it is.  Yet trying to set the value to
nil via `M-x customize-option' fails with the error "This field should
contain an integer", because nil does not fit the customization type
:integer used in the definitions of these user options.  It's been like
this since they were changed from defvars to defcustoms more than 20
years ago (though "If non-nil" was added to the doc strings only a
little less than 10 years ago), so should the fix (below) go into
master, or is it on the order of a documentation fix and suitable for
the release branch?

diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 15f68a62ac..b50b0383da 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -192,11 +192,11 @@ edebug-continue-kbd-macro
 
 (defcustom edebug-print-length 50
   "If non-nil, default value of `print-length' for printing results in Edebug."
-  :type 'integer
+  :type '(choice integer (const nil))
   :group 'edebug)
 (defcustom edebug-print-level 50
   "If non-nil, default value of `print-level' for printing results in Edebug."
-  :type 'integer
+  :type '(choice integer (const nil))
   :group 'edebug)
 (defcustom edebug-print-circle t
   "If non-nil, default value of `print-circle' for printing results in Edebug."


In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-11-18 built on rosalinde
Repository revision: 5d140800398287c20230dda79162a7c40016d88e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: 8.3

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 33428 <at> debbugs.gnu.org
Subject: Re: bug#33428: 27.0.50;
 edebug-print-{length,level} customization types
Date: Mon, 19 Nov 2018 20:37:05 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Mon, 19 Nov 2018 11:32:51 +0100
> 
> The doc strings of edebug-print-length and edebug-print-level imply that
> nil is a valid value and indeed it is.  Yet trying to set the value to
> nil via `M-x customize-option' fails with the error "This field should
> contain an integer", because nil does not fit the customization type
> :integer used in the definitions of these user options.  It's been like
> this since they were changed from defvars to defcustoms more than 20
> years ago (though "If non-nil" was added to the doc strings only a
> little less than 10 years ago), so should the fix (below) go into
> master, or is it on the order of a documentation fix and suitable for
> the release branch?

It's fine with me to put this on the release branch.

Thanks.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33428 <at> debbugs.gnu.org
Subject: Re: bug#33428: 27.0.50;
 edebug-print-{length,level} customization types
Date: Mon, 19 Nov 2018 23:15:21 +0100

On Mon, 19 Nov 2018 20:37:05 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Mon, 19 Nov 2018 11:32:51 +0100
>> 
>> The doc strings of edebug-print-length and edebug-print-level imply that
>> nil is a valid value and indeed it is.  Yet trying to set the value to
>> nil via `M-x customize-option' fails with the error "This field should
>> contain an integer", because nil does not fit the customization type
>> :integer used in the definitions of these user options.  It's been like
>> this since they were changed from defvars to defcustoms more than 20
>> years ago (though "If non-nil" was added to the doc strings only a
>> little less than 10 years ago), so should the fix (below) go into
>> master, or is it on the order of a documentation fix and suitable for
>> the release branch?
>
> It's fine with me to put this on the release branch.
>
> Thanks.

Done in commit d667318a7f.

Steve Berman

Message #16 received at 33428-done <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33428-done <at> debbugs.gnu.org
Subject: Re: bug#33428: 27.0.50;
 edebug-print-{length,level} customization types
Date: Mon, 19 Nov 2018 23:16:59 +0100

On Mon, 19 Nov 2018 23:15:21 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Mon, 19 Nov 2018 20:37:05 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Date: Mon, 19 Nov 2018 11:32:51 +0100
>>> 
>>> The doc strings of edebug-print-length and edebug-print-level imply that
>>> nil is a valid value and indeed it is.  Yet trying to set the value to
>>> nil via `M-x customize-option' fails with the error "This field should
>>> contain an integer", because nil does not fit the customization type
>>> :integer used in the definitions of these user options.  It's been like
>>> this since they were changed from defvars to defcustoms more than 20
>>> years ago (though "If non-nil" was added to the doc strings only a
>>> little less than 10 years ago), so should the fix (below) go into
>>> master, or is it on the order of a documentation fix and suitable for
>>> the release branch?
>>
>> It's fine with me to put this on the release branch.
>>
>> Thanks.
>
> Done in commit d667318a7f.
>
> Steve Berman

Oops, and closing the bug.

Previous Next

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