From: Matt Hodges <MPHodges@member.fsf.org>
Subject: lispref/customize.texi checked.
Date: Mon, 22 Nov 2004 14:55:35 +0000 [thread overview]
Message-ID: <87hdniorvc.fsf@molpro.net> (raw)
[-- 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
next reply other threads:[~2004-11-22 14:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-22 14:55 Matt Hodges [this message]
2004-11-23 6:22 ` lispref/customize.texi checked Juri Linkov
2004-11-23 9:34 ` Matt Hodges
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hdniorvc.fsf@molpro.net \
--to=mphodges@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).