Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Per Abrahamsen]

Use this definition instead:

(defcustom test '((0 . "abc"))
  "xxx"
  :type '(repeat (choice :value "" 
                         (cons :value (0 . "") integer string) 
			 string)))

Explanation:

| Whenever a customize type can be created dynamically, it need to
| have a valid :value attribute to initialize it with.
| 
| Customize typess can be created dynamically if they occur inside a
| 'repeat' or 'choice' type.
| 
| Most atomic types already have valid values, for example the
| `integer' widget had the default :value 0, and the string widget has
| the default
| :value "".
| 
| However, combined types like choice or cons do not have a :value
| that is always valid, it depend on their subtypes.  Therefore, you
| have to specify a valid initial value yourself.

This is a very common error, perhaps the most common error when
creating customize types.  It really should be explained better in the
manual.  Anyone have a suggestion of where and how?

Richard Stallman <rms@gnu.org> writes:

> This seems ot be in the heart of Custom.  Would you please look at it?
>
> From: Jens Schmidt <Jens.Schmidt27@epost.de>
> Subject: Customize creating wrong defaults
> To: bug-gnu-emacs@gnu.org
> Date: 30 Sep 2002 12:44:26 +0100
>
> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English, because the Emacs maintainers do not have
> translators to read other languages for them.
>
> Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
> and to the gnu.emacs.bug news group.
>
> In GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381)
>  of 2001-10-22 on buffy
> configured using `configure --with-msvc (12.00)'
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   locale-coding-system: iso-latin-1
>   default-enable-multibyte-characters: t
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
>
> Eval the following defcustom in an emacs -q:
>
> (defcustom test '((0 . "abc"))
>   "xxx"
>   :type '(repeat (choice (cons integer string) string)))
>
> Then do a M-x customize-variable test RET and press the lower INS
> button.  The result should look like that (note the "invalid"
> list item):
>
> Test: Hide
> INS DEL Choice: Value Menu Cons-cell:
>             Integer: 0
>             String: abc
> INS DEL Choice: Value Menu invalid ((0 ))
> INS
>    State: you have edited the value as text, but you have not set the option.
> xxx
>
>
>
> _______________________________________________
> Bug-gnu-emacs mailing list
> Bug-gnu-emacs@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
> ----------

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Richard Stallman]

Thanks for analyzing the situation.

    This is a very common error, perhaps the most common error when
    creating customize types.  It really should be explained better in the
    manual.  Anyone have a suggestion of where and how?

How about this?  Do it in the node Composite Types, in
lispref/customize.texi, and do it by (1) adding a subnode to explain
the problem and give an examplem and (2) adding a brief note and xref
to that subnode in the vairous table entries for the composite types
for which this is necessary.

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> How about this?  Do it in the node Composite Types, in
> lispref/customize.texi, and do it by (1) adding a subnode to explain
> the problem and give an examplem and (2) adding a brief note and xref
> to that subnode in the vairous table entries for the composite types
> for which this is necessary.

Actually, testing it I found that customize got a good default value
in more cases than I had expected, and a rather simple fix seems to
get the rest of the cases right too.  So let's fix the code instead of
the documentation.

2002-10-02  Per Abrahamsen  <abraham@dina.kvl.dk>

	* wid-edit.el (widget-default-get): Change to return external
	value. 
	(widget-choice-action): Update caller.
	(widget-editable-list-entry-create): Update caller.

cd /home/user_2/abraham/ftp/emacs/lisp/
diff -c wid-edit.el_ORIG wid-edit.el
*** wid-edit.el_ORIG	Wed Oct  2 15:13:47 2002
--- wid-edit.el	Wed Oct  2 15:18:20 2002
***************
*** 508,516 ****
  					 :value-to-internal value)))
  
  (defun widget-default-get (widget)
!   "Extract the default value of WIDGET."
!   (or (widget-get widget :value)
!       (widget-apply widget :default-get)))
  
  (defun widget-match-inline (widget vals)
    "In WIDGET, match the start of VALS."
--- 508,517 ----
  					 :value-to-internal value)))
  
  (defun widget-default-get (widget)
!   "Extract the default external value of WIDGET."
!   (widget-apply widget :value-to-external 
! 		(or (widget-get widget :value)
! 		    (widget-apply widget :default-get))))
  
  (defun widget-match-inline (widget vals)
    "In WIDGET, match the start of VALS."
***************
*** 1993,2001 ****
        (when this-explicit
  	(widget-put widget :explicit-choice current)
  	(widget-put widget :explicit-choice-value (widget-get widget :value)))
!       (widget-value-set
!        widget (widget-apply current
! 			    :value-to-external (widget-default-get current)))
        (widget-setup)
        (widget-apply widget :notify widget event)))
    (run-hook-with-args 'widget-edit-functions widget))
--- 1994,2000 ----
        (when this-explicit
  	(widget-put widget :explicit-choice current)
  	(widget-put widget :explicit-choice-value (widget-get widget :value)))
!       (widget-value-set widget (widget-default-get current))
        (widget-setup)
        (widget-apply widget :notify widget event)))
    (run-hook-with-args 'widget-edit-functions widget))
***************
*** 2621,2629 ****
  		    (setq child (widget-create-child-value
  				 widget type value))
  		  (setq child (widget-create-child-value
! 			       widget type
! 			       (widget-apply type :value-to-external
! 					     (widget-default-get type))))))
  	       (t
  		(error "Unknown escape `%c'" escape)))))
       (widget-put widget
--- 2620,2626 ----
  		    (setq child (widget-create-child-value
  				 widget type value))
  		  (setq child (widget-create-child-value
! 			       widget type (widget-default-get type)))))
  	       (t
  		(error "Unknown escape `%c'" escape)))))
       (widget-put widget

Compilation exited abnormally with code 1 at Wed Oct  2 15:20:07

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Richard Stallman]

    Actually, testing it I found that customize got a good default value
    in more cases than I had expected, and a rather simple fix seems to
    get the rest of the cases right too.  So let's fix the code instead of
    the documentation.

Good news.  Will you go ahead and install that?

Is the :value option still useful, or should we dedocument it?

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     Actually, testing it I found that customize got a good default value
>     in more cases than I had expected, and a rather simple fix seems to
>     get the rest of the cases right too.  So let's fix the code instead of
>     the documentation.
>
> Good news.  Will you go ahead and install that?

I have committed it to CVS.   I committed the other patch as well, it
is a lot less dangerous.

2002-10-02  Per Abrahamsen  <abraham@dina.kvl.dk>

	* wid-edit.el (widget-types-copy): New function.
	(default): Added :copy keyword.
	(menu-choice): Ditto.
	(checklist): Ditto.
	(radio-button-choice): Ditto.
	(editable-list): Ditto.
	(group): Ditto.
	(widget-copy): New function.
	(widget-create-child): Use it.
	(widget-create-child-value): Use it.

It solved the problem reported by Jens where the various choice item
in a

   "(repeat (choice ...))"

affected each other.

> Is the :value option still useful, or should we dedocument it?

Yes, the programmer may know a better initial value than what
customize can come up with.

Re: [Jens.Schmidt27@epost.de: Customize creating wrong defaults]

[Richard Stallman]

Thanks for fixing these things.