lispref/customize.texi checked.

lispref/customize.texi checked.

[Matt Hodges]

[-- Attachment #1: Type: text/plain, Size: 71 bytes --]

Here are some fixes and suggested changes for lispref/customize.texi:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lispref/customize.texi patch. --]
[-- Type: text/x-patch, Size: 7928 bytes --]

*** /scratch/matt/ediff2486435C	Mon Nov 22 14:46:40 2004
--- /home/matt/software/cvs/emacs/lispref/customize.texi	Mon Nov 22 14:21:54 2004
***************
*** 304,310 ****
  
  @example
  (defcustom show-paren-mode nil
!   "Toggle Show Paren mode..."
    :set (lambda (symbol value)
           (show-paren-mode (or value 0)))
    :initialize 'custom-initialize-default
--- 304,310 ----
  
  @example
  (defcustom show-paren-mode nil
!   "Non-nil if Show-Paren mode is enabled..."
    :set (lambda (symbol value)
           (show-paren-mode (or value 0)))
    :initialize 'custom-initialize-default
***************
*** 538,544 ****
                           ("ken"    52 t))
    "Alist of basic info about people.
  Each element has the form (NAME AGE MALE-FLAG)."
!   :type '(alist :value-type (group age boolean)))
  
  (defcustom pets '(("brian")
                    ("dorith" "dog" "guppy")
--- 538,544 ----
                           ("ken"    52 t))
    "Alist of basic info about people.
  Each element has the form (NAME AGE MALE-FLAG)."
!   :type '(alist :value-type (group integer boolean)))
  
  (defcustom pets '(("brian")
                    ("dorith" "dog" "guppy")
***************
*** 665,671 ****
  @end example
  
  @noindent
! so that the menu offers @samp{Number of spaces} and @samp{Literal Text}.
  
  In any alternative for which @code{nil} is not a valid value, other than
  a @code{const}, you should specify a valid default for that alternative
--- 665,671 ----
  @end example
  
  @noindent
! so that the menu offers @samp{Number of spaces} and @samp{Literal text}.
  
  In any alternative for which @code{nil} is not a valid value, other than
  a @code{const}, you should specify a valid default for that alternative
***************
*** 824,831 ****
  Use @var{criteria} to match possible values.  This is used only in
  @code{restricted-sexp}.
  
! @item :args @var{argumentlist}
! Use the elements of @var{argumentlist} as the arguments of the type
  construct.  For instance, @code{(const :args (foo))} is equivalent to
  @code{(const foo)}.  You rarely need to write @code{:args} explicitly,
  because normally the arguments are recognized automatically as
--- 824,831 ----
  Use @var{criteria} to match possible values.  This is used only in
  @code{restricted-sexp}.
  
! @item :args @var{argument-list}
! Use the elements of @var{argument-list} as the arguments of the type
  construct.  For instance, @code{(const :args (foo))} is equivalent to
  @code{(const foo)}.  You rarely need to write @code{:args} explicitly,
  because normally the arguments are recognized automatically as
***************
*** 1071,1077 ****
  using the same type for many user options, rather than repeat the
  specification for each option, you can give the type specification a
  name once, and use that name each @code{defcustom}.  The other case is
! when a user option accept a recursive datastructure.  To make it
  possible for a datatype to refer to itself, it needs to have a name.
  
  Since custom types are implemented as widgets, the way to define a new
--- 1071,1077 ----
  using the same type for many user options, rather than repeat the
  specification for each option, you can give the type specification a
  name once, and use that name each @code{defcustom}.  The other case is
! when a user option accepts a recursive data structure.  To make it
  possible for a datatype to refer to itself, it needs to have a name.
  
  Since custom types are implemented as widgets, the way to define a new
***************
*** 1097,1136 ****
    :type 'binary-tree-of-string)
  @end example
  
! The function to define a new widget is name @code{define-widget}.  The
  first argument is the symbol we want to make a new widget type.  The
  second argument is a symbol representing an existing widget, the new
  widget is going to be defined in terms of difference from the existing
  widget.  For the purpose of defining new customization types, the
! @code{lazy} widget is perfect, because it accept a @code{:type} keyword
  argument with the same syntax as the keyword argument to
  @code{defcustom} with the same name.  The third argument is a
  documentation string for the new widget.  You will be able to see that
  string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string
  @key{ret}} command.
  
! After these mandatory arguments follows the keyword arguments.  The most
  important is @code{:type}, which describes the datatype we want to match
  with this widget.  Here a @code{binary-tree-of-string} is described as
  being either a string, or a cons-cell whose car and cdr are themselves
  both @code{binary-tree-of-string}.  Note the reference to the widget
  type we are currently in the process of defining.  The @code{:tag}
  attribute is a string to name the widget in the user interface, and the
! @code{:offset} argument are there to ensure that child nodes are
! indented four spaces relatively to the parent node, making the tree
  structure apparent in the customization buffer.
  
  The @code{defcustom} shows how the new widget can be used as an ordinary
  customization type.
  
! If you wonder about the name @code{lazy}, know that the other composite
! widgets convert their inferior widgets to internal form when the widget
! is instantiated in a buffer.  This conversion is recursive, so the
! inferior widgets will convert @emph{their} inferior widgets.  If the
! datastructure is itself recursive, this conversion will go on forever,
! or at least until Emacs run out of stack space.  The @code{lazy} widget
! stop this recursion, it will only convert its @code{:type} argument when
! needed.
  
  @ignore
     arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2
--- 1097,1136 ----
    :type 'binary-tree-of-string)
  @end example
  
! The function to define a new widget is called @code{define-widget}.  The
  first argument is the symbol we want to make a new widget type.  The
  second argument is a symbol representing an existing widget, the new
  widget is going to be defined in terms of difference from the existing
  widget.  For the purpose of defining new customization types, the
! @code{lazy} widget is perfect, because it accepts a @code{:type} keyword
  argument with the same syntax as the keyword argument to
  @code{defcustom} with the same name.  The third argument is a
  documentation string for the new widget.  You will be able to see that
  string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string
  @key{ret}} command.
  
! After these mandatory arguments follow the keyword arguments.  The most
  important is @code{:type}, which describes the datatype we want to match
  with this widget.  Here a @code{binary-tree-of-string} is described as
  being either a string, or a cons-cell whose car and cdr are themselves
  both @code{binary-tree-of-string}.  Note the reference to the widget
  type we are currently in the process of defining.  The @code{:tag}
  attribute is a string to name the widget in the user interface, and the
! @code{:offset} argument is there to ensure that child nodes are
! indented four spaces relative to the parent node, making the tree
  structure apparent in the customization buffer.
  
  The @code{defcustom} shows how the new widget can be used as an ordinary
  customization type.
  
! If you are curious about the name @code{lazy}, you need to understand
! that the other composite widgets convert their inferior widgets to an
! internal form when the widget is instantiated in a buffer.  This
! conversion is recursive, so the inferior widgets will convert
! @emph{their} inferior widgets.  If the data structure is itself
! recursive, this conversion will go on forever, or at least until Emacs
! run out of stack space.  The @code{lazy} widget stop this recursion, it
! will only convert its @code{:type} argument when needed.
  
  @ignore
     arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: lispref/customize.texi checked.

[Juri Linkov]

Matt Hodges <MPHodges@member.fsf.org> writes:
> Here are some fixes and suggested changes for lispref/customize.texi:

Thanks for the fixes.

>   @example
>   (defcustom show-paren-mode nil
> !   "Toggle Show Paren mode..."
>     :set (lambda (symbol value)
>            (show-paren-mode (or value 0)))
>     :initialize 'custom-initialize-default
> --- 304,310 ----
>   
>   @example
>   (defcustom show-paren-mode nil
> !   "Non-nil if Show-Paren mode is enabled..."
>     :set (lambda (symbol value)
>            (show-paren-mode (or value 0)))
>     :initialize 'custom-initialize-default

I think show-paren-mode should be replaced with something else.
The line before this example in the manual says:

    Here is an example, from the library `paren.el':

This is not true.  defcustom of show-paren-mode was changed to
define-minor-mode long ago.  There are other real examples with
similar defcustom that could be used instead of show-paren-mode,
e.g. tooltip-mode from tooltip.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: lispref/customize.texi checked.

[Matt Hodges]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

>>>>> Juri Linkov writes:

 > I think show-paren-mode should be replaced with something else. The
 > line before this example in the manual says:

 >     Here is an example, from the library `paren.el':

 > This is not true. defcustom of show-paren-mode was changed to
 > define-minor-mode long ago. There are other real examples with
 > similar defcustom that could be used instead of show-paren-mode,
 > e.g. tooltip-mode from tooltip.el.

I've updated the patch to include this -- I suggest changing the first
line of the tooltip-mode variable documentation from "Toggle
tooltip-mode." to "Non-nil if Tooltip mode is enabled.". I've also
added a few other minor fixes relative to the previous patch.

Thanks,

Matt


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: customize.texi patch. --]
[-- Type: text/x-patch, Size: 9672 bytes --]

Index: customize.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/lispref/customize.texi,v
retrieving revision 1.39
diff -c -r1.39 customize.texi
*** customize.texi	24 Jun 2004 20:17:34 -0000	1.39
--- customize.texi	23 Nov 2004 09:27:14 -0000
***************
*** 300,316 ****
  operation of a certain feature.  Assuming that the package is coded to
  check the value of the option, you still need to arrange for the package
  to be loaded.  You can do that with @code{:require}.  @xref{Common
! Keywords}.  Here is an example, from the library @file{paren.el}:
  
  @example
! (defcustom show-paren-mode nil
!   "Toggle Show Paren mode..."
    :set (lambda (symbol value)
!          (show-paren-mode (or value 0)))
    :initialize 'custom-initialize-default
    :type 'boolean
!   :group 'paren-showing
!   :require 'paren)
  @end example
  
  If a customization item has a type such as @code{hook} or @code{alist},
--- 300,316 ----
  operation of a certain feature.  Assuming that the package is coded to
  check the value of the option, you still need to arrange for the package
  to be loaded.  You can do that with @code{:require}.  @xref{Common
! Keywords}.  Here is an example, from the library @file{tooltip.el}:
  
  @example
! (defcustom tooltip-mode nil
!   "Non-nil if Tooltip mode is enabled..."
    :set (lambda (symbol value)
! 	 (tooltip-mode (or value 0)))
    :initialize 'custom-initialize-default
    :type 'boolean
!   :require 'tooltip
!   :group 'tooltip)
  @end example
  
  If a customization item has a type such as @code{hook} or @code{alist},
***************
*** 529,535 ****
  The @code{group} widget is used here instead of @code{list} only because
  the formatting is better suited for the purpose.
  
! Similarily, you can have alists with more values associated with each
  key, using variations of this trick:
  
  @smallexample
--- 529,535 ----
  The @code{group} widget is used here instead of @code{list} only because
  the formatting is better suited for the purpose.
  
! Similarly, you can have alists with more values associated with each
  key, using variations of this trick:
  
  @smallexample
***************
*** 538,544 ****
                           ("ken"    52 t))
    "Alist of basic info about people.
  Each element has the form (NAME AGE MALE-FLAG)."
!   :type '(alist :value-type (group age boolean)))
  
  (defcustom pets '(("brian")
                    ("dorith" "dog" "guppy")
--- 538,544 ----
                           ("ken"    52 t))
    "Alist of basic info about people.
  Each element has the form (NAME AGE MALE-FLAG)."
!   :type '(alist :value-type (group integer boolean)))
  
  (defcustom pets '(("brian")
                    ("dorith" "dog" "guppy")
***************
*** 665,671 ****
  @end example
  
  @noindent
! so that the menu offers @samp{Number of spaces} and @samp{Literal Text}.
  
  In any alternative for which @code{nil} is not a valid value, other than
  a @code{const}, you should specify a valid default for that alternative
--- 665,671 ----
  @end example
  
  @noindent
! so that the menu offers @samp{Number of spaces} and @samp{Literal text}.
  
  In any alternative for which @code{nil} is not a valid value, other than
  a @code{const}, you should specify a valid default for that alternative
***************
*** 824,831 ****
  Use @var{criteria} to match possible values.  This is used only in
  @code{restricted-sexp}.
  
! @item :args @var{argumentlist}
! Use the elements of @var{argumentlist} as the arguments of the type
  construct.  For instance, @code{(const :args (foo))} is equivalent to
  @code{(const foo)}.  You rarely need to write @code{:args} explicitly,
  because normally the arguments are recognized automatically as
--- 824,831 ----
  Use @var{criteria} to match possible values.  This is used only in
  @code{restricted-sexp}.
  
! @item :args @var{argument-list}
! Use the elements of @var{argument-list} as the arguments of the type
  construct.  For instance, @code{(const :args (foo))} is equivalent to
  @code{(const foo)}.  You rarely need to write @code{:args} explicitly,
  because normally the arguments are recognized automatically as
***************
*** 1071,1078 ****
  using the same type for many user options, rather than repeat the
  specification for each option, you can give the type specification a
  name once, and use that name each @code{defcustom}.  The other case is
! when a user option accept a recursive datastructure.  To make it
! possible for a datatype to refer to itself, it needs to have a name.
  
  Since custom types are implemented as widgets, the way to define a new
  customize type is to define a new widget.  We are not going to describe
--- 1071,1078 ----
  using the same type for many user options, rather than repeat the
  specification for each option, you can give the type specification a
  name once, and use that name each @code{defcustom}.  The other case is
! when a user option accepts a recursive data structure.  To make it
! possible for a data type to refer to itself, it needs to have a name.
  
  Since custom types are implemented as widgets, the way to define a new
  customize type is to define a new widget.  We are not going to describe
***************
*** 1097,1136 ****
    :type 'binary-tree-of-string)
  @end example
  
! The function to define a new widget is name @code{define-widget}.  The
  first argument is the symbol we want to make a new widget type.  The
  second argument is a symbol representing an existing widget, the new
  widget is going to be defined in terms of difference from the existing
  widget.  For the purpose of defining new customization types, the
! @code{lazy} widget is perfect, because it accept a @code{:type} keyword
  argument with the same syntax as the keyword argument to
  @code{defcustom} with the same name.  The third argument is a
  documentation string for the new widget.  You will be able to see that
  string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string
  @key{ret}} command.
  
! After these mandatory arguments follows the keyword arguments.  The most
! important is @code{:type}, which describes the datatype we want to match
  with this widget.  Here a @code{binary-tree-of-string} is described as
  being either a string, or a cons-cell whose car and cdr are themselves
  both @code{binary-tree-of-string}.  Note the reference to the widget
  type we are currently in the process of defining.  The @code{:tag}
  attribute is a string to name the widget in the user interface, and the
! @code{:offset} argument are there to ensure that child nodes are
! indented four spaces relatively to the parent node, making the tree
  structure apparent in the customization buffer.
  
  The @code{defcustom} shows how the new widget can be used as an ordinary
  customization type.
  
! If you wonder about the name @code{lazy}, know that the other composite
! widgets convert their inferior widgets to internal form when the widget
! is instantiated in a buffer.  This conversion is recursive, so the
! inferior widgets will convert @emph{their} inferior widgets.  If the
! datastructure is itself recursive, this conversion will go on forever,
! or at least until Emacs run out of stack space.  The @code{lazy} widget
! stop this recursion, it will only convert its @code{:type} argument when
! needed.
  
  @ignore
     arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2
--- 1097,1136 ----
    :type 'binary-tree-of-string)
  @end example
  
! The function to define a new widget is called @code{define-widget}.  The
  first argument is the symbol we want to make a new widget type.  The
  second argument is a symbol representing an existing widget, the new
  widget is going to be defined in terms of difference from the existing
  widget.  For the purpose of defining new customization types, the
! @code{lazy} widget is perfect, because it accepts a @code{:type} keyword
  argument with the same syntax as the keyword argument to
  @code{defcustom} with the same name.  The third argument is a
  documentation string for the new widget.  You will be able to see that
  string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string
  @key{ret}} command.
  
! After these mandatory arguments follow the keyword arguments.  The most
! important is @code{:type}, which describes the data type we want to match
  with this widget.  Here a @code{binary-tree-of-string} is described as
  being either a string, or a cons-cell whose car and cdr are themselves
  both @code{binary-tree-of-string}.  Note the reference to the widget
  type we are currently in the process of defining.  The @code{:tag}
  attribute is a string to name the widget in the user interface, and the
! @code{:offset} argument is there to ensure that child nodes are
! indented four spaces relative to the parent node, making the tree
  structure apparent in the customization buffer.
  
  The @code{defcustom} shows how the new widget can be used as an ordinary
  customization type.
  
! If you are curious about the name @code{lazy}, you need to understand
! that the other composite widgets convert their inferior widgets to an
! internal form when the widget is instantiated in a buffer.  This
! conversion is recursive, so the inferior widgets will convert
! @emph{their} inferior widgets.  If the data structure is itself
! recursive, this conversion will go on forever, or at least until Emacs
! run out of stack space.  The @code{lazy} widget stop this recursion, it
! will only convert its @code{:type} argument when needed.
  
  @ignore
     arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: tooltip.el patch. --]
[-- Type: text/x-patch, Size: 601 bytes --]

*** tooltip.el	12 Nov 2004 13:47:23 +0000	1.37
--- tooltip.el	23 Nov 2004 09:28:48 +0000	
***************
*** 508,514 ****
  
  ;;;###autoload
  (defcustom tooltip-mode nil
!   "Toggle tooltip-mode.
  Setting this variable directly does not take effect;
  use either \\[customize] or the function `tooltip-mode'."
    :set (lambda (symbol value)
--- 508,514 ----
  
  ;;;###autoload
  (defcustom tooltip-mode nil
!   "Non-nil if Tooltip mode is enabled.
  Setting this variable directly does not take effect;
  use either \\[customize] or the function `tooltip-mode'."
    :set (lambda (symbol value)

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel