diff options
| author | Richard M. Stallman | 2004-11-25 03:09:43 +0000 |
|---|---|---|
| committer | Richard M. Stallman | 2004-11-25 03:09:43 +0000 |
| commit | 38c7d6d55c755f886a5a7f5d80861e53e337b6e5 (patch) | |
| tree | 50c7dfa0eaad1a0c99e5531e4f0c9e8b5cfd9c63 | |
| parent | 0a6d03627fa8d7b018d91d7a0af1c15a72a26310 (diff) | |
| download | emacs-38c7d6d55c755f886a5a7f5d80861e53e337b6e5.tar.gz emacs-38c7d6d55c755f886a5a7f5d80861e53e337b6e5.zip | |
(Variable Definitions): Replace show-paren-mode example with tooltip-mode.
(Simple Types, Composite Types, Defining New Types): Minor cleanups.
| -rw-r--r-- | lispref/customize.texi | 61 |
1 files changed, 30 insertions, 31 deletions
diff --git a/lispref/customize.texi b/lispref/customize.texi index c2e31462e0e..8ad0312e4ea 100644 --- a/lispref/customize.texi +++ b/lispref/customize.texi | |||
| @@ -300,17 +300,17 @@ those other variables already have their intended values. | |||
| 300 | operation of a certain feature. Assuming that the package is coded to | 300 | operation of a certain feature. Assuming that the package is coded to |
| 301 | check the value of the option, you still need to arrange for the package | 301 | check the value of the option, you still need to arrange for the package |
| 302 | to be loaded. You can do that with @code{:require}. @xref{Common | 302 | to be loaded. You can do that with @code{:require}. @xref{Common |
| 303 | Keywords}. Here is an example, from the library @file{paren.el}: | 303 | Keywords}. Here is an example, from the library @file{tooltip.el}: |
| 304 | 304 | ||
| 305 | @example | 305 | @example |
| 306 | (defcustom show-paren-mode nil | 306 | (defcustom tooltip-mode nil |
| 307 | "Toggle Show Paren mode..." | 307 | "Non-nil if Tooltip mode is enabled..." |
| 308 | :set (lambda (symbol value) | 308 | :set (lambda (symbol value) |
| 309 | (show-paren-mode (or value 0))) | 309 | (tooltip-mode (or value 0))) |
| 310 | :initialize 'custom-initialize-default | 310 | :initialize 'custom-initialize-default |
| 311 | :type 'boolean | 311 | :type 'boolean |
| 312 | :group 'paren-showing | 312 | :require 'tooltip |
| 313 | :require 'paren) | 313 | :group 'tooltip) |
| 314 | @end example | 314 | @end example |
| 315 | 315 | ||
| 316 | If a customization item has a type such as @code{hook} or @code{alist}, | 316 | If a customization item has a type such as @code{hook} or @code{alist}, |
| @@ -529,7 +529,7 @@ value. | |||
| 529 | The @code{group} widget is used here instead of @code{list} only because | 529 | The @code{group} widget is used here instead of @code{list} only because |
| 530 | the formatting is better suited for the purpose. | 530 | the formatting is better suited for the purpose. |
| 531 | 531 | ||
| 532 | Similarily, you can have alists with more values associated with each | 532 | Similarly, you can have alists with more values associated with each |
| 533 | key, using variations of this trick: | 533 | key, using variations of this trick: |
| 534 | 534 | ||
| 535 | @smallexample | 535 | @smallexample |
| @@ -538,7 +538,7 @@ key, using variations of this trick: | |||
| 538 | ("ken" 52 t)) | 538 | ("ken" 52 t)) |
| 539 | "Alist of basic info about people. | 539 | "Alist of basic info about people. |
| 540 | Each element has the form (NAME AGE MALE-FLAG)." | 540 | Each element has the form (NAME AGE MALE-FLAG)." |
| 541 | :type '(alist :value-type (group age boolean))) | 541 | :type '(alist :value-type (group integer boolean))) |
| 542 | 542 | ||
| 543 | (defcustom pets '(("brian") | 543 | (defcustom pets '(("brian") |
| 544 | ("dorith" "dog" "guppy") | 544 | ("dorith" "dog" "guppy") |
| @@ -665,7 +665,7 @@ verbatim, you might write the customization type this way, | |||
| 665 | @end example | 665 | @end example |
| 666 | 666 | ||
| 667 | @noindent | 667 | @noindent |
| 668 | so that the menu offers @samp{Number of spaces} and @samp{Literal Text}. | 668 | so that the menu offers @samp{Number of spaces} and @samp{Literal text}. |
| 669 | 669 | ||
| 670 | In any alternative for which @code{nil} is not a valid value, other than | 670 | In any alternative for which @code{nil} is not a valid value, other than |
| 671 | a @code{const}, you should specify a valid default for that alternative | 671 | a @code{const}, you should specify a valid default for that alternative |
| @@ -824,8 +824,8 @@ purposes. This is useful for a type that appears inside of a | |||
| 824 | Use @var{criteria} to match possible values. This is used only in | 824 | Use @var{criteria} to match possible values. This is used only in |
| 825 | @code{restricted-sexp}. | 825 | @code{restricted-sexp}. |
| 826 | 826 | ||
| 827 | @item :args @var{argumentlist} | 827 | @item :args @var{argument-list} |
| 828 | Use the elements of @var{argumentlist} as the arguments of the type | 828 | Use the elements of @var{argument-list} as the arguments of the type |
| 829 | construct. For instance, @code{(const :args (foo))} is equivalent to | 829 | construct. For instance, @code{(const :args (foo))} is equivalent to |
| 830 | @code{(const foo)}. You rarely need to write @code{:args} explicitly, | 830 | @code{(const foo)}. You rarely need to write @code{:args} explicitly, |
| 831 | because normally the arguments are recognized automatically as | 831 | because normally the arguments are recognized automatically as |
| @@ -1066,12 +1066,12 @@ arguments, which will be used when creating the @code{radio-button} or | |||
| 1066 | @subsection Defining New Types | 1066 | @subsection Defining New Types |
| 1067 | 1067 | ||
| 1068 | In the previous sections we have described how to construct elaborate | 1068 | In the previous sections we have described how to construct elaborate |
| 1069 | type specifications for @code{defcustom}. In some cases you may want to | 1069 | type specifications for @code{defcustom}. In some cases you may want |
| 1070 | give such a type specification a name. The obvious case is when you are | 1070 | to give such a type specification a name. The obvious case is when |
| 1071 | using the same type for many user options, rather than repeat the | 1071 | you are using the same type for many user options: rather than repeat |
| 1072 | specification for each option, you can give the type specification a | 1072 | the specification for each option, you can give the type specification |
| 1073 | name once, and use that name each @code{defcustom}. The other case is | 1073 | a name, and use that name each @code{defcustom}. The other case is |
| 1074 | when a user option accept a recursive datastructure. To make it | 1074 | when a user option's value is a recursive data structure. To make it |
| 1075 | possible for a datatype to refer to itself, it needs to have a name. | 1075 | possible for a datatype to refer to itself, it needs to have a name. |
| 1076 | 1076 | ||
| 1077 | Since custom types are implemented as widgets, the way to define a new | 1077 | Since custom types are implemented as widgets, the way to define a new |
| @@ -1097,40 +1097,39 @@ types by a simple example. | |||
| 1097 | :type 'binary-tree-of-string) | 1097 | :type 'binary-tree-of-string) |
| 1098 | @end example | 1098 | @end example |
| 1099 | 1099 | ||
| 1100 | The function to define a new widget is name @code{define-widget}. The | 1100 | The function to define a new widget is called @code{define-widget}. The |
| 1101 | first argument is the symbol we want to make a new widget type. The | 1101 | first argument is the symbol we want to make a new widget type. The |
| 1102 | second argument is a symbol representing an existing widget, the new | 1102 | second argument is a symbol representing an existing widget, the new |
| 1103 | widget is going to be defined in terms of difference from the existing | 1103 | widget is going to be defined in terms of difference from the existing |
| 1104 | widget. For the purpose of defining new customization types, the | 1104 | widget. For the purpose of defining new customization types, the |
| 1105 | @code{lazy} widget is perfect, because it accept a @code{:type} keyword | 1105 | @code{lazy} widget is perfect, because it accepts a @code{:type} keyword |
| 1106 | argument with the same syntax as the keyword argument to | 1106 | argument with the same syntax as the keyword argument to |
| 1107 | @code{defcustom} with the same name. The third argument is a | 1107 | @code{defcustom} with the same name. The third argument is a |
| 1108 | documentation string for the new widget. You will be able to see that | 1108 | documentation string for the new widget. You will be able to see that |
| 1109 | string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string | 1109 | string with the @kbd{M-x widget-browse @key{ret} binary-tree-of-string |
| 1110 | @key{ret}} command. | 1110 | @key{ret}} command. |
| 1111 | 1111 | ||
| 1112 | After these mandatory arguments follows the keyword arguments. The most | 1112 | After these mandatory arguments follow the keyword arguments. The most |
| 1113 | important is @code{:type}, which describes the datatype we want to match | 1113 | important is @code{:type}, which describes the data type we want to match |
| 1114 | with this widget. Here a @code{binary-tree-of-string} is described as | 1114 | with this widget. Here a @code{binary-tree-of-string} is described as |
| 1115 | being either a string, or a cons-cell whose car and cdr are themselves | 1115 | being either a string, or a cons-cell whose car and cdr are themselves |
| 1116 | both @code{binary-tree-of-string}. Note the reference to the widget | 1116 | both @code{binary-tree-of-string}. Note the reference to the widget |
| 1117 | type we are currently in the process of defining. The @code{:tag} | 1117 | type we are currently in the process of defining. The @code{:tag} |
| 1118 | attribute is a string to name the widget in the user interface, and the | 1118 | attribute is a string to name the widget in the user interface, and the |
| 1119 | @code{:offset} argument are there to ensure that child nodes are | 1119 | @code{:offset} argument is there to ensure that child nodes are |
| 1120 | indented four spaces relatively to the parent node, making the tree | 1120 | indented four spaces relative to the parent node, making the tree |
| 1121 | structure apparent in the customization buffer. | 1121 | structure apparent in the customization buffer. |
| 1122 | 1122 | ||
| 1123 | The @code{defcustom} shows how the new widget can be used as an ordinary | 1123 | The @code{defcustom} shows how the new widget can be used as an ordinary |
| 1124 | customization type. | 1124 | customization type. |
| 1125 | 1125 | ||
| 1126 | If you wonder about the name @code{lazy}, know that the other composite | 1126 | The reason for the name @code{lazy} is that the other composite |
| 1127 | widgets convert their inferior widgets to internal form when the widget | 1127 | widgets convert their inferior widgets to internal form when the |
| 1128 | is instantiated in a buffer. This conversion is recursive, so the | 1128 | widget is instantiated in a buffer. This conversion is recursive, so |
| 1129 | inferior widgets will convert @emph{their} inferior widgets. If the | 1129 | the inferior widgets will convert @emph{their} inferior widgets. If |
| 1130 | datastructure is itself recursive, this conversion will go on forever, | 1130 | the data structure is itself recursive, this conversion is an infinite |
| 1131 | or at least until Emacs run out of stack space. The @code{lazy} widget | 1131 | recursion. The @code{lazy} widget prevents the recursion: it convert |
| 1132 | stop this recursion, it will only convert its @code{:type} argument when | 1132 | its @code{:type} argument only when needed. |
| 1133 | needed. | ||
| 1134 | 1133 | ||
| 1135 | @ignore | 1134 | @ignore |
| 1136 | arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2 | 1135 | arch-tag: d1b8fad3-f48c-4ce4-a402-f73b5ef19bd2 |