GNU bug report logs -
#33428
27.0.50; edebug-print-{length,level} customization types
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Mon, 19 Nov 2018 10:34:01 UTC
Severity: normal
Found in version 27.0.50
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#33428: 27.0.50; edebug-print-{length,level} customization types
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 33428 <at> debbugs.gnu.org.
--
33428: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33428
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 6 years and 180 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.